From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2568 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: is it required to call kill() from process #1 ? Date: Sun, 5 May 2019 02:52:10 +0200 Message-ID: <20190505005207.GE2595@panda> References: <11997211556565598@myt6-27270b78ac4f.qloud-c.yandex.net> <20190501033355.6e41e707@mydesk.domain.cxm> <20616231556847420@myt3-2475c4d2af83.qloud-c.yandex.net> Reply-To: sysinit@yandex.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="91293"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.0 (2018-05-17) To: supervision@List.skarnet.org Original-X-From: supervision-return-2158-gcsg-supervision=m.gmane.org@list.skarnet.org Sun May 05 02:52:23 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hN5OB-000NbG-1e for gcsg-supervision@m.gmane.org; Sun, 05 May 2019 02:52:23 +0200 Original-Received: (qmail 6478 invoked by uid 89); 5 May 2019 00:52:41 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 6471 invoked from network); 5 May 2019 00:52:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1557017533; bh=DpiRbTzgAA93RUVJWOFOAoVd/qUzuDEZ6rl8Rtr28aI=; h=In-Reply-To:Reply-To:Subject:To:From:References:Date:Message-ID; b=fE6AArZzqkM/8S12gKivkGecHvczum0AtQuhLTGUSC+kmoAbOuIhqjoDP/zFck31d EvdGy/OTCHA1b8XZBCm18uZ7PvXezkPUP5lziUysQNYs3x6kW7Blj4iNOMMCge7dNZ z7yImm3jOJ3UZfqWOP2COW4Ry/ZtfiDL4/3A1Nrk= Authentication-Results: mxback6j.mail.yandex.net; dkim=pass header.i=@yandex.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2568 Archived-At: > Before the reboot(2) system call, at some point you need to > kill all processes ("kill -9 -1") so you can unmount filesystems > and *then* call reboot(2). indeed. > That's relying on a behaviour that Linux implements, and possibly > BSD too, but that is not specified in POSIX: that the process > that does a kill(-1, signal) is not affected by the kill() call. true when using kill( -1, sig ). > With the extended behaviour, the process that performs the kill -9 -1 > survives, and can then go on to "stage 4", i.e. unmounting everything > and telling the hardware to halt/reboot. But that is not POSIX. > POSIX specifies that the kill signal will be sent to all processes > "excluding an unspecified set of system processes". pid 1 is naturally > part of those "system processes", but a shell, or a program that > performs the shutdown sequence, with a random pid, cannot be. there are at least to other solutions to the killall problem: * on Linux you probably have the procfs mounted, on the BSDs, Solaris, and AIX you can use kvm to do the following: find all running processes (except your own and possibly your own session id) via the procfs or kvm and signal them, your own process (and session) are now not signaled (this is how the killall5 utility actually works). in the case of kvm you do not even need to have the procfs mounted. * if you can not rely on such a mechanism you can still do a brute-force search to find running processes along this pseudo code lines: pid_t p ; const pid_t mypid = getpid () ; const ... int u = get_current_upper_limit_for_the_number_of_procs () ; for ( p = 2 ; u >= p ; ++ p ) { // this ignores session ids if ( mypid != p && 0 == kill ( p, 0 ) ) { (void) kill ( p, signal ) ; } } i personally do it from process #1 aswell since calling kill( -1, sig ) from there is much simpler and should be faster (work is done by the kernel, no need to find all running processes by ourselves). > The only ways to perform a proper shutdown sequence that strictly > conforms to POSIX are: > - do it in pid 1 > - do it *under a supervision tree*. When the shutdown sequence kills > everything, it may also kill itself; if it is the case, it is restarted > by the supervision tree, and can then go on to stage 4. i prefer to call it "stage 3b". :PP stage 3a terminates known services. then everything is killed by process #1 and stage 3b is run thereafter to complete the remaining shutdown tasks like swapoff and unmounting the fs. BTW: i do not un/remount pseudo fs like procfs, sysfs, devtmpfs etc whose mountpoints are directly located on the root fs or via a direct path of pseudo fs from the root fs. works well when one does not use initram and the like. could this cause trouble somewhere ? > The shutdown sequence generated by the current s6-linux-init-maker > does the former. The shutdown sequence in the upcoming s6-linux-init > performs the latter. ok, when will you release it ? you made me curious ... > It is not strictly necessary to do so on Linux, and apparently on > BSD either, since those systems ensure the survival of the process > sending the big nuke. But you need to be aware of this implementation > detail before advertising the "classical BSD way". :) :PP actually it may not since it looks like inherited behaviour from even older Unix implentations' init. the Linux SysV init incarnation and minit also do not run any of the system shutdown tasks themselves but instead delegate these to subprocesses.