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

[Joshua Judson Rosen]

Bill Freeman <ke1g.nh at 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 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.

According to FHS, and the reference systems that I have on-hand
(Debian 7, Ubuntu 12.04, OpenSuSe 11.3), /tmp fits your criteria:

    * It's world-writable, so every user can create PID-files there.
    * It's cleared at boot.

(the `tmp' variant that's *not* cleared at boot is /var/tmp)


Alternately, some of the usual options of which I'm aware:

     * if ! killall -0 $PROGRAM # it's not running,
                                # or it's not us running it...

     * if ! kill -0 "$(cat $PIDFILE)" # it's not running,
                                      # or it's not us running it,
                                      # or we can't read the $PIDFILE

     * On Debian-based systems, use "start-stop-daemon"

     * Have the process hold $PIDFILE open, and then
       if ! fuser -s $PIDFILE # it's not running as far as we can tell

> So, can I count on parent pid, or maybe process group id, to identify the at
> boot time case?  Or would that be unwise?

It may or may not be unwise in your particular case, but it would
certainly be unusual.

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."