[systemd-devel] Is sd_journal_send non-blocking?

[Lennart Poettering]

On Mon, 06.02.17 13:25, Florian Weimer (fweimer at redhat.com) wrote:

> > The socket we use is blocking, but we try to increase the socket
> > buffer to 8M, to move the point where we start to block out late. But
> > that only works with sufficient privileges.
> 
> The sender buffer size is currently a limit on the datagram size.  The data
> goes straight into the receiver's buffer, so it doesn't have any impact on
> blocking behavior.

Well, the receiver buffer islarge anyway, it's journald on the other
side, and that is privileged.

> > So yes, we are always blocking, we don't throw data away.
> 
> Sure.  I was wondering if indefinite blocking is considered a critical
> service failure and if there is a watchdog which would catch a stuck journal
> daemon.

The watchdog logic is enabled for journald, and it's at 3min by
default, if that's what are you asking?

> > I'd be willing to take a patch however, that adds a call
> > sd_journal_set_block_timeout() or so, that takes a time value we pass
> > to SO_SNDTIMEO for the logging socket. This would permit clients to
> > precisely control how long they want us to wait before we give up. And
> > in the case where a zero timeout is set we'd instead set O_NONBLOCK,
> > thus making logging entirely non-blocking.
> 
> This would help with discarding data.  It would not help those who want to
> integrate logging into an event loop.  Which is probably bad idea anyway,
> but I'm not quite sure yet what the purpose of non-blocking logging is.
> Perhaps there is a desire to apply some back-pressure to reduce the rate at
> which logging messages are generated.  But in general, this merely
> introduces deadlocks.

We could expose the logging socket too, so that people could poll() on
it. But uh, I seriously doubt this is actually a good idea...

Lennart

-- 
Lennart Poettering, Red Hat