Expected behaviour when pid file is removed (externally)?

[hongkongkiwi]

In my testing when I remove the pid file manually with an rm -f /run/myapp.pid, finit doesn't take any action.

Should this take action ? What is expected behaviour in this case?

It seems to put finit in a state which is out of sync because the app is still running, finit knows the app is still running with initctl status myapp but initctl cond dump shows that init knows the pid condition is no longer active.

I think it would be great to have an option (or a default behaviour) where finit will restart the app if there was a pid file and something externally removes it. OR perhaps finit can simply recreate the pid file based on it's known pid.

Or.... any other ideas about this?

[troglobit]

This behavior is by design. Actually, it's a delicately crafted design even.

Finit monitors services, this is its primary purpose. The condition subsystem is built as an extension for this, e.g. for synchronizing other services.

PID files are an age old UNIX thing. It's not standardized how they should be used, or what their meaning is, but a de facto use-case is as a means of telling the rest of the system "I'm done with my setup, I'll be running on this PID, it's safe to send me signals now." -- so a service removing its PID file could simply mean; "busy, don't contact me now", or it could mean that the service is just in the process of recreating that file (removing it, being scheduled out for a period of time, and then recreating it), or that some system mechanism (external to Finit) want's to prevent depending services to run ... bad example maybe, but the point. Having Finit react to, and stopping, a service that loses its PID file would be cause some very shaky behavior.

I'm fine classifying your removal of the PID file as an unexpected external event and closing this.