Re: correct pid file handling

From: Kieran Simkin (kieran_at_digital-crocus.com)
Date: 06/09/04


Date: Wed, 9 Jun 2004 22:41:35 +0100


"Ara.T.Howard" <Ara.T.Howard@noaa.gov> wrote in message
news:Pine.LNX.4.60.0406082200020.27511@harp.ngdc.noaa.gov...
>
> say you have a daemon which creates a pidfile. upon finding an existing
> pidfile, is it really the best thing to try to kill the process identified
in
> the pidfile? it's possible that this pid may be owned by another,
unrelated,
> process and that this process would then be inadvertently killed! what is
> 'the right thing' to do in general?

As far as I know there's no universally accepted "right thing to do".
However, here's what I do in my daemons:

1) check pid file size is 0 bytes, if not - fail to start with an error
2) write pid to pidfile
3) setup signal handlers for SIGTERM, SIGINT and SIGQUIT to truncate pidfile
to 0 bytes

That way, the only time the pidfile will be stale is if the entire system
crashes and you can bet if this happens I'll be looking at the system very
closely anyway to find out what's wrong. If your system makes a habit of
randomly crashing, you should look into this, not work around it in your
daemon. If the system is rebooted in the normal way, all processes receive a
SIGTERM, and this will result in the pidfile being truncated to 0 bytes so
that's no problem.

If you have multiple instances of your daemons running concurrently as
different users, they should be writing to different pidfiles anyway - each
pidfile should be owned by the user the daemon's running as and users can't
kill eachother's processes anyway. If you have multiple instances of your
daemons all running as the same user, what is the purpose of your pidfile?

Your pidfile behaviour is really dictated by how your daemon is supposed to
work and what it's supposed to achieve. If you consider how you want your
daemon to behave under different circumstances, how its pidfile should be
managed should become clear. If not, post some more details and we'll see if
we can help.

>
> thanks.
>
> -a
> --
>
============================================================================
===
> | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> | PHONE :: 303.497.6469
> | A flower falls, even though we love it; and a weed grows, even though we
do
> | not love it. --Dogen
>
============================================================================
===



Relevant Pages

  • Re: pidfile_check() possible function
    ... +> I've just had a situation, where I want to know the pid of the already running daemon, but i don't want to create the pidfile in case if there is no daemon running. ...
    (freebsd-current)
  • Re: correct pid file handling
    ... > daemon to behave under different circumstances, how its pidfile should be ... then i have the issue of whether a give pid is still bound the the process ...
    (comp.unix.programmer)
  • pidfile_check() possible function
    ... I've just had a situation, where I want to know the pid of the already running daemon, but i don't want to create the pidfile in case if there is no daemon running. ...
    (freebsd-current)
  • Re: correct pid file handling
    ... On Wed, 9 Jun 2004, Eric Enright wrote: ... >> say you have a daemon which creates a pidfile. ... > existance of the PID file, and refuse to start until the offending process ...
    (comp.unix.programmer)
  • New library: libpidfile.
    ... It is something that is used by quite every daemon, ... Most important thing about this library, is that created pidfile is ... to take advantage of libpidfile and only kill process from the given ... Libpidfile has four functions to offer, but it will be easiest to just show ...
    (freebsd-arch)