Hi, I'll try to summarize what was already said:
- in this particular scenario, there is little that can be done on
rsyslog's side
- the fact that imuxsock gets messages through journald limits its
ability to do any rate limiting / flow control
- rsyslog can get all the messages that journald has through the
imjournal plugin
The behavior of imuxsock has changed in that previously the services
calling syslog() blocked on the call until the message was written to
the socket. journald, as it seems, tries to write the message and
discards it if it fails. I'd say this is a regression that needs to be
addressed. journald should provide some means of flow control where one
specifies whether messages should be dropped at all or how large a
backlog it should keep. This will use up some memory but only for bursts.
On 07/12/2013 11:03 AM, Jonny Törnbom wrote:
On Thu, Jul 11, 2013 at 08:53:57PM +0200, David Lang wrote:
I don't understand what you think the problem is.
The problem is that we lose messages at boot-up.
You have disabled the ability for the journal to buffer things, and then you
want to know why there isn't a buffer.
I have disabled storing of messages from journal (see why below). The
storage setting of journal does _not_ affect the socket buffering of the
forwarding socket.
reconfigure storage to the default instead of none and it sounds like things
will 'just work'
As I wrote in my previous email we are on an embedded system with
limited resources. Storing duplicates of messages is not an option.
Reconfiguring storage to default will _not_ make it work. We will still
drop messages at boot-up since the forwarding socket is getting full.
As I see it, you can't change the buffer of the socket, journald can't
buffer the messages pending on the socket, but perhaps you can use a
workaround using imjournal:
You would need to enable journald's volatile storage so the messages get
to rsyslog at all, but configure the rotation so that the ones journald
keeps are discarded in a short time frame. There are MaxRetentionSec=
and RuntimeMaxUse= directives which might enable you to do this.
Disclaimer: I haven't tried it myself.
We are bugging the "other mailing list" about the issue and will
hopefully come up with a solution.
I'd be interested in that discussion, could you please provide a link?
HTH,
Tomas
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
