From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2652 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6-linux-init: Actions after unmounting filesystems Date: Sun, 18 Aug 2019 12:08:55 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="59934"; mail-complaints-to="usenet@blaine.gmane.org" To: Supervision Original-X-From: supervision-return-2242-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Aug 18 17:09:11 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 1hzMnu-000FRi-9B for gcsg-supervision@m.gmane.org; Sun, 18 Aug 2019 17:09:10 +0200 Original-Received: (qmail 2421 invoked by uid 89); 18 Aug 2019 15:09:34 -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 2414 invoked from network); 18 Aug 2019 15:09:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=T33GA2J+cHekxkwO48yKDCOKoZSff3HIv4SJ4MLSyiQ=; b=LbHbWoBrb23jQJEQm+2KX2z6SBNHHhiaAlhIWVnPKXza0RV2iT2ixiR0F2cUMDGaQN wZuHmvATjYRhSk0ZslVMf8D4EOwFLpSo8QSo/60mFJ+rW0/TbiMe5uCjA+iduaDS5w6J VuHx60UDzISHK9AEsO8LPdc0xbuNHFzxdLfcOOZWNdsUOC+VEfsmFGO03O3Dpf4RMCfc D9c5ydla1wN1Q12WOq+/2HQTFS1QJi6BDNgX2XNCh3wNptgCgGv1SEE6Yl3LwTxaOI9r 5K0imyAemq7/DRYV/eMTQn1iC+iyl2grT7NsH8Cnhc1MuZN/E3lDISXHpmAky6l+PdgF NEkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=T33GA2J+cHekxkwO48yKDCOKoZSff3HIv4SJ4MLSyiQ=; b=Bd4fKxwI9qWXVMOPgiIh7GKCxO/mXQJjqaxoamr0nZImwThpZHcD6qGkcBdutgvgaI QiZ6VJIVbcIX8/aOzlo3rdzQc7alB/nUg1nMiyttdMkndYg9C639fV+f2RQZYRCt+J/O jU4hrOj7Ee9FutwKPt+keh3WrU3kPCrmakKrsE9Bdp2BPmLGROapWkwkAkWuX0iH8V1q 5JqyXj8wy0N9LyqdyrniUkvmwMngwovBb18i0qmN27iwd+avsYlq0FK7LijTx+e3AWXB Fdb8gNyPPQqeRoQ986hv8XbJTEU7MWQycCZUSIGmiek8tIMWxFE5DW9MO2YvNRo7B5qW /L0Q== X-Gm-Message-State: APjAAAWxjuNRP2Zjx+9o0vY4U77losSKjYkZbGyhpT90noTyPVQUEGWo lSaDwtBAnvy27hkKdac32OQipjtG5rdNNWa9ticpvQ== X-Google-Smtp-Source: APXvYqwkX6xJ9H/083dF0IU8IbcfH4jPIUnUROOCL2S9yEqmdxQ27O6R9mdFgPZifq0Atm/mK5UpA93/M+2kMNMWkaM= X-Received: by 2002:a6b:4107:: with SMTP id n7mr8708535ioa.12.1566140946600; Sun, 18 Aug 2019 08:09:06 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2652 Archived-At: El s=C3=A1b., 17 ago. 2019 a las 20:01, Laurent Bercot escribi=C3=B3: > > - If a filesystem can track all the processes that have a handle on > it, it is possible to have it be mounted/unmounted symmetrically by > the service manager. I don't think there are filesystems that can do that? > At unmount time, kill the processes that would > block the unmount operation, then perform the unmount, then run the > additional commands. In that case it's all done at the service manager > level, s6-linux-init doesn't have to do anything. That's OpenRC's approach, except it does not rely on filesystem features. It just uses 'fuser -m -k'. But it leads to code that's quite ugly I think, compared to the simplicity of s6-linux-init's 'kill(-1, SIGTERM)' + 'kill(-1, SIGKILL)': * https://github.com/OpenRC/openrc/blob/882c6bf3bcaba6903d9dc593f8ae41e505b= 4e4e7/sh/rc-mount.sh (mountinfo is another OpenRC internal command) > - There could be a hook in the autogenerated stage 4 script, which > runs a user-provider script, something like rc.shutdown.after-umount. This is probably better, but I'd also like to hear other opinions. > I don't much like giving control to a user script at that level, when > there are no services running and no mounted filesystems, possibly > not even /proc or /sys, You'd probably have to make some exclusions in s6-linux-init-umountall, like Casper said. Maybe parse the fstype field in /proc/mounts lines and omit sysfs, proc, tmpfs and devtmpfs? BTW, OpenRC also does exclusions, via --skip-point-regex and --skip-fstype-regex options passed to mountinfo (see do_unmount invocations in services localmount and mount-ro). I admit this complicates s6-linux-init-umountall. > and when a hang in a user script could > very well prevent a clean reboot I haven't thougt of that. Ouch. Maybe a mechanism like the one s6-supervise uses to limit execution of the finish file in s6-linux-init-shutdownd, or some shutdown hook runner? I admit it complicates s6-linux-init-shutdownd :) > Admins/distros would have to make sure the deactivate_* functions > only call binaries that are on the root filesystem. It is obvious to me that it must be that way, but in this era in which some distributions want to put every executable in /usr/bin and mount /usr from an initramfs, who knows :P But that's the distribution's job, I agree. G. G.