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
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
On 05/21/2013 11:22 AM, Bill Freeman 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
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
Bill Freeman 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.
I'm not specifically answering your question here, but, here is some
code that I believe to be reasonable and related to the problem you
appear to
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
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
Bill Freeman ke1g...@gmail.com writes:
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 sticky-bit
