From owner-cvs-etc Mon Jun 2 23:31:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09961 for cvs-etc-outgoing; Mon, 2 Jun 1997 23:31:18 -0700 (PDT) Received: from androcles.com (androcles.com [204.57.240.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09864; Mon, 2 Jun 1997 23:29:48 -0700 (PDT) Received: (from dhh@localhost) by androcles.com (8.8.5/8.6.12) id XAA19614; Mon, 2 Jun 1997 23:30:20 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <33930CFD.794BDF32@whistle.com> Date: Mon, 02 Jun 1997 22:56:04 -0700 (PDT) From: "Duane H. Hesser" To: Julian Elischer Subject: Re: cvs commit: src/etc rc Cc: cvs-etc@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Adam David , =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= , Peter Wemm Sender: owner-cvs-etc@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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