> On Fri, 09.09.11 13:57, Marti Raudsepp ([email protected]) wrote: >> Tom Gundersen on #systemd reduced the problem down to this: "telinit u >> && reboot" >> When I run the above, I get into the same state that /sbin/reboot >> doesn't function.
On Tue, Sep 20, 2011 at 04:47, Lennart Poettering <[email protected]> wrote: > Try to use gdb on systemd-initctl and check if you can figure out where > the service chokes on the commands. I finally got around to debugging this further and found the problem. When systemd-initctl is launched, it opens a connection to the systemd D-Bus socket straight away. After executing "telinit u", systemd-initctl sends a SIGTERM signal back to systemd, forcing it to reexec. When systemd starts up again, the old D-Bus connection from initctl is no longer functional, thus it can't tell systemd to reboot. I was looking at the wrong log file before, so I missed these messages: Oct 27 19:13:11 arch systemd-initctl[409]: Failed to start unit: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Oct 27 19:13:19 arch systemd-initctl[409]: Failed to start unit: Connection is closed I'm not sure what the right fix is. Here's what occured to me: 1. Don't open a D-Bus connection from systemd-initctl at startup time, but only for the duration of sending a message. 2. Create a retry wrapper around dbus_connection_send_with_reply_and_block() to reconnect to D-Bus when sending fails. 3. Change systemd not to break existing D-Bus connections on daemon-reexec -- not sure if possible 4. Use prctl(PR_SET_PDEATHSIG, SIGTERM); in systemd-initctl. This way the kernel terminates the initctl daemon every time systemd re-executes, but this is racy. Regards, Marti _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
