Date: Mon, 02 Jun 1997 22:56:04 -0700 (PDT) From: "Duane H. Hesser" <alex@androcles.com> To: Julian Elischer <julian@whistle.com> Cc: cvs-etc@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Adam David <adam@veda.is>, =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>, Peter Wemm <peter@spinner.dialix.com.au> Subject: Re: cvs commit: src/etc rc Message-ID: <XFMail.970602233020.alex@androcles.com> In-Reply-To: <33930CFD.794BDF32@whistle.com>
index | next in thread | previous in thread | raw e-mail
Umm...sorry to intrude on your thread, guys (throw me out if you
like), but I think I'm a little confused about WHICH problem you're
talking about (maybe I missed something?).
There are two possible problems with lock files that I know about.
One is easy, the other a little harder, and at least the easy one
can be handled pretty handily from shell scripts (as well as C).
1) dead or 'stale' locks:
if test kill -0 `cat PIDFILE`
then
do what you do if the process LIVES
else
RIP
fi
...or the C equivalent.
This supposes that the pid file contains the PID and only
the pid
2) wraparound--the demon dies and sometime later another process
re-uses the pid. Problem (1) is actually fairly frequent...some
dummy (not me, no NEVER me...) does a 'kill -9', or the SIGSEGV
demon randomly kills a perfectly good program...
(2) is less likely. In 18 years of watching closely I've never
seen one demon assume another's process identity. It COULD
happen, and it could HAVE happened, but I'd like to think I
would've noticed. No matter, it could happen. Still, 'ps -c'
(if I remember) prints from p_comm, rather than the arg string,
and I don't think a process is able to mangle that easily, is
it? I suppose that you could say that if it does, it deserves
it's fate. Forgive me, that is unkind...
So what IS the problem? What am I missing? I agree that taking an
flock on a pid file is a nice idea, so long as you can afford an
open fd, but it doesn't seem to me that revising code (except maybe
some shell scripts) is necessary to check for dead locks. I (for
one) would be willing to take my chances on the wraparound problem.
But please, NO MORE symbolic lunks! Please? I don't think I could
STAND another symbolic lunk.
Duane H. Hesser
dhh@androcles.com
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970602233020.alex>