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

[Lennart Poettering]

On Sun, 29.05.16 13:28, Felix Miata (mrmazda at earthlink.net) wrote:

> Lennart Poettering composed on 2016-05-29 18:40 (UTC+0200):
> 
> >Felix Miata wrote:
> 
> >>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...
> 
> Now that I know this isn't something familiar to you, I'll be on the watch
> to collect specifics to report next time I encounter it. Will there be a
> specific journalctl option to use at that time, or will -b do it?

"journalctl -b" shows you everything that happened during your current
boot. If you are trying to find log data generated during shutdown
this probably won't give you what you want, as you probably want the
data from the previous boot, not the current one, i.e. "journalctl
-b-1" is what you want...

That said, the journal itself is also terminated at shutdown. It's
terminated quite late, but it might happen that something that also
runs pretty late isn't covered anymore. This is harder to debug, and
documented here:

https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Lennart

-- 
Lennart Poettering, Red Hat