Bill Freeman <ke1g...@gmail.com> writes: > I'm trying to figure out whether to force the removal of an almost certainly > stale pid file or not in the service start case. > > While I presume that the start up sequence normally handles this by clearing / > var/run before lighting off the init scripts for the level, I have a need to > have my pid file in an unusual place (needs to be written and deleted by a > non-root process). > > I'd like start at boot to be automatic, and if shutdown was clean, it will > be. But if the system crashes (or someone hits the reset button, etc.) there > will be a stale pid file come boot time. > > I'd like to automatically delete any stale pid file at boot time, but start > later should fail claiming that there's an existing process.
According to FHS, and the reference systems that I have on-hand (Debian 7, Ubuntu 12.04, OpenSuSe 11.3), /tmp fits your criteria: * It's world-writable, so every user can create PID-files there. * It's cleared at boot. (the `tmp' variant that's *not* cleared at boot is /var/tmp) Alternately, some of the usual options of which I'm aware: * if ! killall -0 $PROGRAM # it's not running, # or it's not us running it... * if ! kill -0 "$(cat $PIDFILE)" # it's not running, # or it's not us running it, # or we can't read the $PIDFILE * On Debian-based systems, use "start-stop-daemon" * Have the process hold $PIDFILE open, and then if ! fuser -s $PIDFILE # it's not running as far as we can tell > So, can I count on parent pid, or maybe process group id, to identify the at > boot time case? Or would that be unwise? It may or may not be unwise in your particular case, but it would certainly be unusual. -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))." _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/