0

I have several different services that can self-restart (e.g. after an auto-update). Unfortunately, when they restart, they do not come up. I can tell because service <service name> status tells me it inactive, and it is not listed with ps. I believe that systemd will kill the service as soon as the main executable dies. The logs do not show any signs of errors.

The service is defines as a systemd service, of Type=simple and without a PIDfile=. I like to keep it this way, because systemd 'owns' the process (thus knows the PID) and I do not have to create a writeable folder in /var/run/ first.

Is there any way to tell systemd to 'rescan' for the newly start process when the original started process died? Note that systemd should not restart the service, therefore most restart-related options I found in the manual don't apply.

OS: Ubuntu 15.04, systemd 219.

0

No, there is not. This is a hard limitation imposed by systemd, and a substantial breaking change to the expectation of how processes work. I really hope that I'm wrong here, and I just haven't found it yet.

FWIW, you're not alone. The best suggestions so far are to use at, cron, or systemd timer units. I understand if that's small consolation to you.

2

Is there any way to tell systemd to 'rescan' for another executable when the original executable died?

Executables do not die. Processes die. Get the question right, and the answer appears. Is there a way to tell systemd about a new main service process and hand over to it so that the old main service process can quietly exit? Yes, there is. It's the notify readiness protocol.

I've never tried it myself, but the way of doing this in the systemd model is for the current main process to spawn the replacement service running the new program image, then sd_notify systemd about the new MAINPID, handing over the main process torch to the new one, and then exit. (It gets slightly more complex if the old main process has to negotiate handover with the new main process.)

As I said, I've never used this, and I cannot speak to any regressions in the intervening years, but back in 2011 this is how people were reportedly solving this particular problem.

(The other design is, of course, not to have self-modifying service programs, but to have separate "update" services that run outwith the execution context of the service whose program is being upgraded.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.