[systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID

Lennart Poettering lennart at poettering.net
Tue Jan 18 14:38:34 PST 2011


On Tue, 18.01.11 17:56, Alexander E. Patrakov (patrakov at gmail.com) wrote:

> 18.01.2011 16:51, Lennart Poettering пишет:
> >On Tue, 18.01.11 16:41, Alexander E. Patrakov (patrakov at gmail.com) wrote:
> >
> >>>How is this implemented in detail? Sending SIGINT is async, so at the
> >>>time you start the new instance you cannot be sure that the old instance
> >>>has stopped listening?
> >>Indeed, there is a race here. That's why "/bin/sleep 1" in my
> >>initial service file.
> >Hmm, what's the lighthttp people's take on this? They came up with the
> >scheme, so how do they think this problem should be handled?
> 
> They usleep(5 * 1000) and, if the new copy of lighttpd still fails
> to start due to a race, sleep again and attempt to start it again,
> ad infinitum.

Meh, busy loops like this are equal.
> 
> >(One possible solution could be if the old and the new instance would
> >communicate and pass the listening sockets via some AF_UNIX
> >socket/SCM_RIGHTS or so. But that is not trivial.)
> 
> I came with a different (albeit systemd-specific) solution. The
> solution (implemented as an attached patch) is to fork() after we
> closed all the listening sockets and exit immediately in the parent.
> This way, the chlid continues to serve already-requested files, and
> systemd has a race-free indication that it can restart lighttpd via
> Restart=always. Please review the patch and the service file. One
> known problem: the patch is completely untested with
> server.max-worker > 0.

fork()ing is ugly, will break all mutexes, eat all threads and is
otherwise ugly too. Using fork() is in itself a problem, seldom a
solution.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list