Date: Tue, 21 Jan 1997 23:29:22 +0000 (GMT) From: Adam David <adam@veda.is> To: freebsd-hackers@freebsd.org Subject: reboot(8) and slow-dying processes Message-ID: <199701212329.XAA00566@veda.is>
next in thread | raw e-mail | index | archive | help
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/<pid> (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 <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701212329.XAA00566>