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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
