[systemd-devel] Assertion failed in systemd v16

[Marius Tolzmann]

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
  -> 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 considered issuing a "systemctl reload" in the main-process to let 
systemd reload the whole service where ReloadExec would spawn the new 
instance which kills the old one. But the ReloadExec would never return 
and so the state of the service would probably be "reloading" or 
something and the new MAINPID should be the one of ReloadExec-process..
..this does not seem to work at all..

how is this supposed to be handled in systemd??

m.