[systemd-devel] [PATCH] core: switch to journal when socket is listening

[Lennart Poettering]

On Wed, 19.06.13 13:36, Umut Tezduyar (umut at tezduyar.com) wrote:

> Hi Lennart,
> 
> I didn't quite understand how this could end up in a deadlock
> (http://lists.freedesktop.org/archives/systemd-devel/2013-June/011404.html)

Here's an example:

a) PID 1 is running, journald is not, the socket is already established

b) PID 1 wants to log 20 log lines, writes those to the journal
   socket. 

c) However, after 15 lines the socket is full, the kernel
   refuses to queue more messages in it, and our log call starts to
   block on it.

d) Normally, if something is queued on the socket, we'd go and activate
   journald, which would then dispatch the messages. However, we cannot
   do this in this case, because we are still stuck in the logging
   calls. And as long as that is the case we cannot return to the main
   event loop and notice that the socket has EPOLLIN and then spawn
   journald for it.

e) deadlock! We wait for journald to process our messages, but journald
   cannot be started before we stopped waiting for it.

> I think in general we could be having a problem when a service could
> be started by both socket activation and as part of a target.wants. It
> could be that first data coming in the socket might trigger an event
> that is being caught by systemd but not the service itself (even
> though service is up) and this might cause the service receive the
> first package delayed (in the event of the next data).

Well, that's why I am saying that when the service changes state this
should always be fed back to the socket, so that systemd doesn't need to
to see the EPOLLIN...

Hope that makes sense?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.