I went with the keep the file open approach, but added flock exclusive (advisory locking). When starting, if the file exists, but if I can open it for writing and flock it exclusive, I assume that it's a stale PID file and just delete it.
On Tue, May 21, 2013 at 4:15 PM, Bill Freeman <ke1g...@gmail.com> wrote: > 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/