[systemd-devel] Assertion failed in systemd v16

[Lennart Poettering]

On Tue, 18.01.11 14:04, Marius Tolzmann (tolzmann at molgen.mpg.de) wrote:

> 
> hi..
> 
> On 01/18/11 13:30, Alexander E. Patrakov wrote:
> >
> >>As you noticed, this changes the PID, and systemd currently cannot
> >>handle this.
> >>
> >>We could however reload the PID file after a reload completed I
> >>guess. (/me adds this to the todo list)
> >
> >Well, there are cases (live update of nginx, see
> >http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly)
> >where the main PID would change without the explicit "systemctl reload"
> >command. In the case of nginx, one can follow up the live update with a
> >dummy "systemctl reload", so I am not sure if it matters.
> >
> >OTOH, maybe it would be better to evaluate the main PID lazily when it
> >is needed, instead of trying to enumerate all places where it can change
> >and reloading it there. But this way we will also hide all races caused
> >by bad PID file handling logic, so I am not sure.
> 
> 
> we too use software where the MAINPID changes over time due to
> automatic/on-the-fly reloading of the main binary..
> 
> that is how the on-the-fly logic is implemented:
> when the modification of the binary is detected

I am not a big fan of such a logic for two reasons: a) it's incredible
hard to respawn like this if *any* of the loaded code blobs are change
(i.e. an app is seldom just a single binary, but uses shared libraries
and loadable modules) and b) if multiple things change it is hard to
impossible to find the right time where really everything has been fully
updated, i.e. you might end up with a half-updated process in the end.

>  -> the server will spawn a new main process (new MAINPID)
>  -> when successfully initialized
>       -> the new process will kill the old one
>  -> else (on failure) the old process continues until the next
>     modification is detected
> 
> systemd is not notified..

I guess in this case too sd_notify(3) could be of help, and the least
ugly solution.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.