[systemd-devel] failing boot start jobs delay reboot

[Andrei Borzenkov]

On Tue, Jan 20, 2015 at 7:03 AM, Felix Miata <mrmazda at earthlink.net> wrote:
> Andrei Borzenkov composed on 2015-01-20 06:35 (UTC+0300):
>
>> Mon, 19 Jan 2015 17:59:41 -0500 Felix Miata composed:
>
>>> Has anything been done in more recent releases about this? I do a lot of
>>> cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
>>> produces long delays in init followed by emergency mode when the
>>> non-essential mount fails and fstab for that device does not include the
>>> nofail option. When I recognize early in init that I have made a fstab typo,
>>> I try to CAD to choose another boot choice that isn't broken and fix the
>>> typo, but that produces yet another start job wait for the same broken job,
>>> often followed by a gazillion failed to save sound card state messages from
>>> holding down CAD.
>
>>> openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
>>> comprise most of my installations subject to these self-inflicted delays that
>>> I can't recall being a problem with sysvinit.
>
>> "Self inflicted delays" during boot or during Ctrl-Alt-Del?
>
> Both.

Back upon a time initscripts used delays as well waiting for devices
to appear. I think later it was basically converted to wait for
udevsettle. For usual end user system udevsettle does not do much and
so is more or less instant.

I'm not sure whether this will be feasible today as default solution.
You could try experimenting with adding x-systemd.device-timeout=1s to
/etc/fstab and forcing udevsettle before local-fs-pre.target.

>          When they occur during init they repeat during shutdown. Even when I
> let init complete and succeed to fix the typo or oversight, the init failure
> gets remembered and repeated at shutdown.

Yes, that's the problem. For once, traditional workflow of

- stop in emergency shell when mount fails
- fix /etc/fstab
- ^D to continue boot

no more works, because /etc/fstab is not reevaluated so systemd will
still try the same broken mount again. Also I have observed delays
during shutdown/reboot /probably/ triggered by failed mounts but am
not sure how to reproduce them. If you have simple step by step guide
how to trigger such delays, would be great.

>                                                                   Often the start job is on account
> of a volume label that has been replaced, usually along with a UUID, because
> the clone is a partition on the same HD. Fedora is particularly frustrating
> by embedding dependent root volume label and not obeying root= on cmdline
> (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
> dracut.
> --