That should work fine. The lock would be cleared if the reset button is pressed.
On 05/21/2013 06:33 PM, Bill Freeman wrote: > 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 > <mailto: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 > <mailto: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 > > -- Jerry Feldman <g...@blu.org> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90 _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
