Bug#762700: systemd: journald fails to forward most boot messages to syslog

[Christian Seiler]

Am 2015-03-03 16:26, schrieb Michael Biebl:
> I did a couple more reboots and did indeed run into the problem, that
> systemd-sysctl.service was started after syslog.socket, so I got the
> "missed XXX messages" again.
> Adding the After=systemd-sysctl.service ordering to syslog.socket 
> fixed
> that. In [1] you mentioned, that a sysctl snippet is no option. Can 
> you
> elaborate why? I'd really like to avoid shipping an extra service for
> this. Since systemd-sysctl.service uses DefaultDependencies=no as 
> well,
> it can run pretty early.

Danger! This could result in a deadlock.

journald.service: After=syslog.socket (which is correct, otherwise
messages will be silently discarded because it will get -ENOENT and
think syslog is inactive anyway).

syslog.socket: After=systemd-systctl.service

systemd-sysctl.service:
After=systemd-readahead-collect.service 
systemd-readahead-replay.service
After=systemd-modules-load.service

Even if you discard the readahead service, systemd-modules-load.service
will generate log messages (1 for each module). Those log messages are
then sent to the journal, which is not started yet (but its socket is),
the default queue length for the kernel applies also here, but because
logging is blocking (see shared/log.c, write_to_journal()), if the
queue is full it will wait until the journal has collected the
messages. But now you have the situation that journald is implicitly
ordered after this service, so during the runtime of this service
journald will never start and things deadlock.

You can probably trigger this by putting 12 modules into
/etc/modules-load.d. Each one will generate a message for the journal
and after the 11th the service will hang. Jupp, just tried it,
deadlocks. Will, kind-of, because after ~15s it will somehow still
boot, I don't quite understand it, but I don't think this is fine the
way it is.

Christian