08.03.2016 12:16, Carlos E. R. пишет:
Each Unix socket has fixed size buffer for sent data. If there is no space to store incoming message, normally sender would block. This is acceptable when you have many clients each sending messages to logging daemon independently; you can tolerate accidental sleep of some of them. But in case of systemd there is single process - journald - that is syslogd client and journald is not allowed to block indefinitely. So it is using non-blocking mode and simply discards messages if it cannot send them to syslogd (meaning - socket buffer is full).
But AFAIK no messages were lost before systemd started handling the log.
Yes, that's true. I do not say this is not a problem.
In case of rsyslog the solution is actually to use rsyslog journald support that pulls data itself.
Is that the default, or do I have to do something?
I do not know if this is default in openSUSE package. Otherwise you need to configure corresponding driver.
Workaround is to increase socket buffer size for journald - syslogd communication. E.g. current upstream systemd syslog.service sets
[Socket] ... ReceiveBuffer=8M
Is that accessible to admins (where), or is it a build option?
Yes, of course. You can add drop-in to set (change) it; but I looked at 13.2, Leap and TW (all with up to date patches) and all of them already have the same value. So if this problem is observed on any of these systems, there must be another reason. I remember this was discussed upstream, but I forgot what was the resolution.
This should give more headroom to smooth bursts of activity.
I guess it should be.