From owner-cvs-etc Mon Jun 2 15:04:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15584 for cvs-etc-outgoing; Mon, 2 Jun 1997 15:04:18 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15423; Mon, 2 Jun 1997 15:02:29 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id PAA15362; Mon, 2 Jun 1997 15:02:16 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id WAA10666; Mon, 2 Jun 1997 22:27:08 GMT From: Adam David Message-Id: <199706022227.WAA10666@veda.is> Subject: Re: cvs commit: src/etc rc In-Reply-To: from "[______ ______]" at "Jun 3, 97 00:42:00 am" To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Mon, 2 Jun 1997 22:27:07 +0000 (GMT) Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-etc@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-etc@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > IMHO, if the program wipes its name out altogether it deserves whatever crap > > it gets. > > Program name not related to its pid file, you try to introduce unnecesarry > restriction. I already stated that it is necessary to know both names in order to check. It is only when the program clobbers itself that it gets into trouble. If a program is so paranoid as to erase its tracks entirely, it has no business maintaining pidfiles. > If program not test pid file via flock(), it deserves ... I.e. all > programs except gated and few others got what they want. So, they require > modifications to check locking, so it is impossible to validate pid files > without applications modifications (as I already say in previous letter). #!/bin/sh kill `cat /var/run/progname.pid` (yes, there are programs that make the assumption that pidfiles exist for the duration of a programs execution, and not a moment longer). Most of the time when the program has expired, it will produce an unexpected and often confusing error, but occasionally it hits the wrong program altogether. Even once is too often. It is not the offender that suffers but an innocent bystander. (randomly directed violence) I have also seen stale locks, but not on a healthy system. (file claims to be locked, but no process holds the lock). > Modification of each such application is not acceptable solution. Each such application already uses its own methods, which are demonstrably deficient in many cases. -- Adam David