'Twas brillig, and Colin Guthrie at 14/01/14 12:57 did gyre and gimble: > Looking again, it seems as if "systemctl daemon-reexec; systemctl > daemon-reexec" can also trigger the problem...
OK, so from the last couple days of debugging, I can see two problems where this problem occurs. 1. If systemctl has an open bus connection, runs chkconfig which in turn runs systemctl daemon-reload, and then after execing, calls the Reload action on the bus, bad things happen. This could be just a general race, as it seems that running two "systemctl --no-block daemon-reload" comamnds in rapid succession also triggers the problem. 2. If you run two "systemctl daemon-reexec" in rapid succession, the first returns quickly (on bus disconnect) and then the second starts running (at least on a fast CPU/SSD) before the first has a chance to finish. This is likely the same problem as above, but you don't need --no-block here due to the implicit disconnection resulting from a reexec which makes it non-blocking by default. 3. Some sort of kernel trigger for me today led it to run two reexecs quite quickly and triggered this problem randomly during runtime. This *might* have come in via "telinit u" instead. It doesn't appear that the kernel actually execs telinit directly but perhaps userspace can react on it in some way? That's all I've got so far. Sorry for the messages, but hoping someone will step in and help me debug this one as it's pretty tricky to poke at :( Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
