On Wed, 19.06.13 13:36, Umut Tezduyar (u...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
