[00:08] Keybuk: regarding the sigstop/sigcont issue [00:08] it seems that sendsigs tries to kill its parent process and upstart respawns it [00:09] so I naively tried to add -o $PPID to the killall5 call [00:09] but that didn't help [00:09] have you investigated this further already? [00:25] Curious. If i use mountall --debug ... >/dev/mountall.log 2>&1 in mountall.conf, it’s as if two separate instances are writing to the log file at the same time. [02:28] mbiebl: it doesn't try and kill it [02:28] the bug is simply that sendsigs is doing something ridiculous [02:29] but it isn't even a bug, nothing bad is happening [02:34] what happens is that killall5 (called by sendsigs) sends SIGSTOP to all processes [02:34] then it reads /proc [02:34] then it sends those processes SIGTERM [02:34] then it sends SIGCONT [02:34] the idea of the STOP/CONT being that it prevents new processes from being spawned while it's reading /proc [02:34] it has to stop all processes [02:34] and then it does this over and over again in a loop, until no processes are left [02:35] while it ignores some pids (including its parent) for the purposes of sending SIGTERM and may be left afterwards, it still sends them SIGSTOP [02:35] it's silly [02:35] because it's trying to win a race [02:35] but it's just doping it [02:36] most particularly, because init itself ignores SIGSTOP ;) [02:36] so init can always spawn new processes if it likes [02:36] so rcS isn't dying or being respawned [02:36] the shell associated with it is just getting hammered by SIGSTOP/SIGCONT signal pairs until all *other* processes on the system have died [02:36] (sendsigs "ignores" rcS itself, since it's its parent) [02:37] if you see it going on for a long time, it means that _some_other_ process is not terminating [02:37] even with SIGKILL [02:37] that implies one in uninterruptible sleep in the kernel [02:37] sendsigs/killall5 don't handle this [09:24] Keybuk: thanks for the explanation