How can I detect whether an /etc/rc.d/init.d script is being run at boot time versus by hand?

Bill Freeman ke1g.nh at gmail.com
Tue May 21 18:33:54 EDT 2013


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.nh at 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.nh at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20130521/ed7d4db6/attachment.html 


More information about the gnhlug-discuss mailing list