Am 2015-03-20 06:25, schrieb Michael Biebl:
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.
Huh, weird.
So I guess I'll merge your patch as is, including the upstream
commit.
Thanks!
I've been running with both patches applied for a while and didn't
have
a single missed message since then.
I've encountered it at one point so far (with the service, which I've
been using otherwise without any problems since I've reported this
bug):
a daemon decided to go on a rampage (partly because of
misconfiguration,
partly because it doesn't handle misconfiguration well) and started to
produce lots and lots of log messages, in just 1h my /var/log/syslog
grew to 2.4 GiB (the journal, storage only being in /run, was rotate
probably 100 times or so while this was happening). But I'd argue there
that if something goes THIS crazy, all sorts of other stuff may break
(most notably, /var running out of diskspace, because syslog files are
only rotated daily), so I don't view this as an issue with systemd.
Just wanted to mention this because the setting makes syslog forwarding
robust enough from my perspective, but not bulletproof.
Christian
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
