supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Guillermo <gdiazhartusch@gmail.com>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: s6-linux-init: Actions after unmounting filesystems
Date: Sun, 18 Aug 2019 12:08:55 -0300	[thread overview]
Message-ID: <CADQ2Nw9HROBfim44y9it-sZ0T3YjkyWD-j_U9iKj76-QMdaD-w@mail.gmail.com> (raw)
In-Reply-To: <em288742c3-85c4-4256-aa86-c196ef57db87@elzian>

El sáb., 17 ago. 2019 a las 20:01, Laurent Bercot escribió:
>
> - 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/882c6bf3bcaba6903d9dc593f8ae41e505b4e4e7/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.


  parent reply	other threads:[~2019-08-18 15:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-17 19:14 Guillermo
2019-08-17 23:01 ` Laurent Bercot
2019-08-18  4:09   ` Casper Ti. Vector
     [not found]   ` <20190818040925.yqy4nm7cwsnrtyjl@caspervector>
2019-08-18  6:26     ` Laurent Bercot
2019-08-18  8:34       ` Casper Ti. Vector
2019-08-18 16:18       ` Samuel Holland
2019-08-18 18:35         ` Laurent Bercot
2019-08-18 19:28           ` Guillermo
2019-08-18 20:36             ` Oliver Schad
2019-08-18 15:08   ` Guillermo [this message]
2019-08-18 21:36 ` Brett Neumeier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADQ2Nw9HROBfim44y9it-sZ0T3YjkyWD-j_U9iKj76-QMdaD-w@mail.gmail.com \
    --to=gdiazhartusch@gmail.com \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).