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

[Michael Biebl]

Am 03.03.2015 um 16:48 schrieb 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.

I myself couldn't reproduce the problem with putting 12 modules inot
/etc/modules.

That said, your reasoning is sound, so let's not take any chances.

Shipping a separate .service unit also has one little benefit: It will
only be pulled if, if there actually is a syslogger in socket-activation
mode.
I.e., if you don't have any syslogger installed, or you configure
rsyslog to use imjournal, systemd-setup-dgram-qlen.service would not be
pulled in.

So I guess I'll merge your patch as is, including the upstream commit.

I've been running with both patches applied for a while and didn't have
a single missed message since then.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150320/bcdb6e55/attachment-0002.sig>