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 16:15:39 EDT 2013


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/d1f80089/attachment.html 


More information about the gnhlug-discuss mailing list