[systemd-devel] After upgrading glibc: Received environment initctl request

[Marti Raudsepp]

> On Fri, 09.09.11 13:57, Marti Raudsepp (marti at juffo.org) 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
<lennart at poettering.net> 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