[Pkg-systemd-maintainers] Bug#718038: Bug#718038: systemd fails shut

[Michael Stapelberg]

Hi Joey,

Joey Hess <joeyh at debian.org> writes:
> Version: 44-12
Note that we also have 204-2 in experimental. It’d be interesting to see
if the failure mode has changed in that version.

> But for entirely different reasons; I have no encrypted filesystems to
> fail; in my case a locally written /etc/network/if-up.d/local was trying
> to start aiccu when lo came up, which basically deadlocked things.
> (I did not bother waiting 5 minutes to see if systemd would time it
> out.)
I tried reproducing your issue by creating /etc/network/if-up.d/local
containing "#!/bin/sh\nsleep 5d" and making it executable, but my
machine boots fine (with systemd 204, though).

Could you provide the precise contents of that file that lead to the
lock-up please? Also, just in case we still cannot reproduce the issue
afterwards, could you boot with systemd.log_level=debug (and without
quiet) and provide the output? You can dump it using dmesg once you
actually reach a shell, which should be a matter of letting it time out.

Also, booting with systemd.confirm_spawn=1 might be helpful. It will ask
you for confirmation before spawning each unit, so this should help you
figure out which unit precisely is the problem here.

> 1. With the default "quiet" boot parameter, systemd outputs very little
>    useful information.
>    But, d-i started adding "quiet" to grub command lines only to suppress
>    verbose and generally not useful kernel messages; the intent was not
>    to make the init system so quiet that the user can't tell what's
>    going on!
This can easily be fixed by adding systemd.show_status=1 to the cmdline.
Given that d-i does not install systemd by default, this is a manual
step currently.

> 2. Why does networking need to come up before gettys are started? My
>    laptop has no network filesystems. The only failure mode that should
>    prevent a getty from being started should be a fsck failure or root
>    filesystem mount failure, which should lead to a recovery shell.
>    Systemd has failure modes where no shell is started.
The getty service file has no dependency on the network.

> The combination of these behaviors yields a system that fails shut;
> it can't easily be debugged without an arbitrary amount of complication.
Well, that is a bit of an exaggeration :).
There is http://freedesktop.org/wiki/Software/systemd/Debugging/ which
describes a number of steps that you can take to end up with a running
system and/or get more information about what failed.

> (Now happily running systemd for the first time. README.Debian
> seems out of date re su exit code being busted by PAM, and lightdm works
> which it didn't used to.)
Indeed, thanks. I’ve fixed this with
http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=6ae0edf

-- 
Best regards,
Michael