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

[Umut Tezduyar]

On Thu, Jun 20, 2013 at 9:15 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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?
Hi. It makes perfect sense. While manager is waiting to process
journal sockets event, it is blocked writing something on the filled
up journal socket. However, I think a deadlock will never occur as
systemd-journald.service is wanted by sysinit.target. Having said
that, I do agree about the recommended change. Thanks.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.