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

[Michael Biebl]

Am 03.03.2015 um 16:26 schrieb Christian Seiler:
> Am 2015-03-03 15:33, schrieb Michael Biebl:
>> Am 02.03.2015 um 15:42 schrieb Christian Seiler:
>>
>>>  - SOLUTION (mostly the same as before, but SendBuffer is set on a
>>>    different unit and a Condition is added to the service):
>>>
>>>       1. Increase max_dgram_qlen to a reasonable value. The easiest
>>>          way is via a systemd service:
>>>
>>>          /lib/systemd/system/systemd-setup-dgram-qlen.service:
>>>          [Unit]
>>>          DefaultDependencies=no
>>>          Before=syslog.socket
>>>          ConditionPathIsReadWrite=/proc/sys/net/unix/max_dgram_qlen
>>>
>>>          [Service]
>>>          Type=oneshot
>>>          ExecStart=/sbin/sysctl -w net.unix.max_dgram_qlen=512
>>>          StandardOutput=null
>>
>> A proper Description= is missing and it probably should have
>> RemainAfterExit=yes.
>> That said, why not simply use a sysctl.d conf snippet?
> 
> systemd-sysctl.service is not ordered before the socket.

Yeah, see my other followup email. Can be fixed by adding
After=systemd-sysctl.service to syslog.socket.

 Also it's
> ordered after a bunch of services, and syslog.socket is typically
> available really early.

The only service I see ordered before systemd-sysctl.service is
systemd-modules-load.service, and that one looks unproblematic, i.e. not
something which would delay the start of syslog.socket noticeably.

Then there is the proposed RequiresMountsFor=/usr/lib/sysctl.d/ which
can translate into After=usr.mount, for a split-usr setup.

In both cases, I don't see it leading to a regression compared to
sysvinit, do you?


>>> I've been using this on a Jessie system for the past couple of days
>>> (well, drop-ins in /etc, actually), and I didn't notice any
>>> side-effects so far.
>>
>> Did you run it with 1. and 2. applied, or only 1.?
> 
> Only 1. so far. And 2. may not be necessary.

[..]

> So if the sysctl is reliably set before the socket is created, we
> should be good, the buffer size change is probably not needed unless
> there are REALLY long log messages.

Given that it has been applied upstream
(5e8b767df6e18444d5aff2987b5e5603361ed528), I personally wouldn't mind
cherry-picking that patch.


-- 
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/20150303/96a0d863/attachment-0002.sig>