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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
