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/
