[systemd-devel] shutdown delayed by failure to start a service

[Lennart Poettering]

On Sat, 28.05.16 04:42, Felix Miata (mrmazda at earthlink.net) wrote:

> Mantas Mikulėnas composed on 2016-05-27 20:05 (UTC+0300):
> 
> >Lennart Poettering wrote:
> 
> >>Felix Miata wrote:
> 
> >>>Did this ever get fixed? IOW, sometimes a service will fail to start when a
> >>>system is started, or later, after a session of updating, a previously
> >>>operating service fails to restart, or a newly installed service fails to
> >>>start, or a service is removed. Then at shutdown/reboot time, systemd pauses
> >>>90 seconds with a message about trying to *start* a service. I think I most
> >>>often notice this when I try to hold down CAD after a normal shutdown/reboot
> >>>order gets stuck or seemingly ignored. At such times I typically see an
> >>>"endless" string of failing to save sound card state messages.
> 
> >>I have never heard of something like this. And what you describe is
> >>not really how systemd works. At shutdown, we actually only shut down
> >>services, we don't start any.
> 
> The message I see is equivalent in form as during boot, e.g. when a
> filesystem not noauto in fstab is to be mounted but cannot be found, so a
> delay of typically 90sec, but sometimes much longer, occurs. Mount
> specification mistyped or a subsequently changed volume label, or similarly
> a change of filesystem UUID should be an easy enough way to observe what
> I've not infrequently seen, though the cause(s) of the more irritating
> shutdown delays isn't coming to mind ATM. If this was something I had a
> reliable recreate scenario for I'd have filed a bug somewhere by now, likely
> at least a year ago.

Well, we put a timeout of 90s on *everything* systemd starts or
stops. Hence, saying that you see some 90s timeout just means
*something* isn't finishing as quickly as it should, with exactly zero
information about what that something might be...

Lennart

-- 
Lennart Poettering, Red Hat