On Mon, 06.02.17 13:25, Florian Weimer (fwei...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
