From owner-freebsd-hackers Tue Jan 21 15:21:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA21431 for hackers-outgoing; Tue, 21 Jan 1997 15:21:10 -0800 (PST) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA21425 for ; Tue, 21 Jan 1997 15:21:05 -0800 (PST) Received: (from adam@localhost) by veda.is (8.8.4/8.7.3) id XAA00566 for freebsd-hackers@freebsd.org; Tue, 21 Jan 1997 23:29:23 GMT From: Adam David Message-Id: <199701212329.XAA00566@veda.is> Subject: reboot(8) and slow-dying processes To: freebsd-hackers@freebsd.org Date: Tue, 21 Jan 1997 23:29:22 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk reboot(8) is very unforgiving in that it only allows 5 seconds for processes to tidy up and exit gracefully, but there may be processes that need a longer delay before they are slaughtered as a last resort (for instance large database applications). So I was thinking of a mechanism whereby a process can assert that it might need a longer dying period. Such processes could be specifically tested for whether they are finished, before the axe is made to fall on all and sundry. It is unreasonable to assume that all processes need this service, since most have absolutely no use for it, and it would add unnecessary overhead. It is not really acceptable to have a separate program, let's say nice_reboot (and nice_halt) to deal with the extra work, although this could be hidden to some degree behind shutdown(8). I was thinking along the lines of using /var/run/slowkill/ (perhaps checked against process starttime in case of abnormal termination and subsequent reuse of the pid by some other program). However this is not an agreeable storage method since the directory would have to be world writeable and sticky, and this is a flawed idea anyway. It would be somewhat cleaner to flag the process in the kernel, but this seems like unwelcome bloat. As an altogether cleaner approach, would it make sense for reboot(8) to retry the SIGTERM several times (in similar fashion to the eventual retry of SIGKILL) and redefine the -f flag to mean "force" (i.e. present behaviour) for shutdown(8) and reboot(8)? This would have the advantage of needing no extra mechanism. What opinions do people have on the subject of this or more acceptable solutions? -- Adam David