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? > Add the following to /lib/systemd/systemd/syslog.socket: > Wants=systemd-setup-dgram-qlen.service > 2. Make it even more robust by applying the patch from upstream > to increase the send buffer on the socket journald uses to > forward syslog messages, i.e. add > SendBuffer=8M > to /lib/systemd/system/systemd-journald-dev-log.socket > (NOT syslog.socket!) > > (As said before, the values 512 and 8M are debatable, although 8M is > typically used within systemd's source code, so it's probably a good > value to use. 512 seems like a reasonable compromise to me: typically, > up to ~ 100 boot messages will be generated before syslog is started > on systems I've tried this on, so using something that's 5x higher > seems like a good safety net without increasing this to crazy high > numbers. Note that the 8M limit will apply independently.) > > 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.? -- 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
