Thanks to all. Some notes:
The session id/group id/ppid thoughts are a non starter. I've found that, at least on CentOS, they aren't small recognizable numbers at boot time. I can probably count on running on a linux box, so I can probably count on the FHS. But the downside of tmp is that any process can also delete my pid file (as opposed to having to be either root or the user created for the program). The keep it open and use fuser -s approach sounds interesting. Too bad linux doesn't support the old exclusive non-creating open, or I could have a cheaper test than running a sub-process (I'm doing the PID file managment as part of a python program, by the way). I guess I'll read up on file locking, which I hope goes away over a re-boot. On Tue, May 21, 2013 at 11:22 AM, Bill Freeman <ke1g...@gmail.com> wrote: > 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. > > So, can I count on parent pid, or maybe process group id, to identify the > at boot time case? Or would that be unwise? > > Bill >
_______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
