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

[Lennart Poettering]

On Thu, 27.10.11 19:39, Marti Raudsepp (marti at juffo.org) wrote:

> 
> > 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.

Ah, thanks for tracking this down!

> 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.

I have now commited a simple fix that will simply cause initctl to
terminate itself after sending SIGTERM. If there's more data queued in
the FIFO then systemd will respawn us anew, so things should be fine.

I didn't really give this much testing, so it would be good if you could
check out if this works for you!

http://cgit.freedesktop.org/systemd/patch/?id=f632a6634dd4eff041425aa9b3fb48ccfa98c014

Thanks!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.