[gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Duncan]

Rich Freeman posted on Wed, 17 Feb 2016 08:46:34 -0500 as excerpted:

> On Tue, Feb 16, 2016 at 9:20 PM, Duncan <1i5t5.duncan@×××.net> wrote:
>>
>> Initial shutdown is via two targets (as opposed to specific services),
>
> Since not everybody in this thread may be familiar with systemd, I'll
> just add a quick definition.

Thanks for this followup. =:^)

> When systemd says "target" - think "virtual service."  The equivalent in
> openrc would be an init.d script that has dependencies but which doesn't
> actually launch any processes.
>
> Targets also take the place of runlevels in systemd.

The systemd official comparison of targets is to runlevels, except much 
more flexible as it's actually possible for multiple targets to be in the 
process of being reached at once, not services or "virtual services", and 
indeed, my immediate internal reaction at seeing the "virtual services" 
definition was "no, they're like runlevels", before I even reached the 
next paragraph, where you add that.

Basically, I'd put the runlevel comparison first and primary, as systemd 
documentation does, tho now that I've seen the usage, "virtual services" 
/does/ add some richness to the definition, helping to accent the fact 
that multiple targets can be processed at once.  So it's a difference in 
emphasis, while agreeing in general.

> Just as with runlevels in openrc they are used to synchronize milestones
> during bootup, but the design is much more generic. Presumably openrc
> hard-codes runlevels like sysinit, boot, and default.  In systemd I
> believe it just looks at the config file and directly launches the
> desired target, and then the dependency chain for that pulls in all the
> targets that precede it.  Targets can depend on other targets, and
> services can depend on previous targets.
>
> The other dimension is that unit files describe what target they are
> typically associated with if it isn't the default.  So, you don't run
> into the sorts of situations you have with openrc that if you want to
> enable mdraid support you need to remember to add it to the boot
> runlevel.  That might be a relatively-easy thing to add support for in
> openrc actually.
>
> Hopefully that makes Dunan's summary easier to read for anybody who
> doesn't speak systemdese.

Again, thanks. =:^)

> Another bit of background that might be helpful is that systemd also
> manages mounts directly.

After actually looking into how systemd processes mounts as I wrote the 
earlier post, I believe it's safe to say this is a much bigger difference 
than it might seem on the surface, and it was certainly one of the 
biggest challenges I faced in attempting to explain systemd's mount 
processing in sysvinit/openrc terms.

Even with a reasonable level of personal admin-level systemd familiarity, 
I kept expecting and looking for systemd to hand off the unmounting to a 
service, which I expected would simply call one of the separate from 
systemd itself executables (for example journald, networkd, etc, I was 
expecting a mount helper or mountd as well), only after seeing the 
shutdown flowchart and looking into each individual component, I still 
couldn't find it, which is why I ultimately had to go diving directly 
into the systemd sources themselves, which is when I found what I was 
looking for! =:^)

But in hindsight, while there are various non-systemd-binary executables 
that ship with systemd, systemd itself directly processes all unit files, 
including mount units, so I should have known that it'd handle umounting 
directly.  But I simply didn't make that connection, until it became 
obvious after the fact, and indeed, it didn't actually solidify in my 
mind until just now as I wrote about it, tho certainly, after writing the 
earlier post, all the pieces were there to be assembled, and this simply 
triggered it. =:^)

> It parses fstab and creates a network of mount
> units with appropriate dependencies.  Whether you unmount /var/tmp using
> "umount /var/tmp" or "systemctl stop var-tmp.mount" systemd updates the
> status of the var-tmp.mount unit to a stopped status.  I believe if you
> add a noauto line to fstab it will create a mount unit automatically and
> not start it, and if you made it mount on boot I think it would actually
> be mounted as soon as you save the file in your editor (systemd can
> monitor config files for changes - all of this is governed by
> scripts/software called generators).

I'm not sure of the last -- systemd does let you mount and umount at will
[1], and there are enough cases where an admin might setup the fstab 
entry before he's actually prepared for the mount to go ahead, that I 
don't believe it would be wise for systemd to try to jump the gun.

OTOH, it's possible to setup corresponding *.automount units as well, 
with the purpose there being to trigger mounting (using the kernel's 
automount services, which of course would have to be enabled -- they 
aren't here) as soon as something tries to stat/open a path under that 
mount point.  If you setup both the fstab (triggering mount unit 
generation) and automount units, and then referenced something under it, 
/then/ systemd would do the automount. =:^)

Of course, if someone's sufficiently interested in the outcome, it should 
be relatively easy to test, at least for those /running/ systemd.  I 
don't personally happen to be /that/ interested in the outcome, however, 
so...

> So, systemd in general tries to stay aware of the state of mounts.  I
> suspect that isn't just firing off a script to find/unmount anything
> that is mounted.  From Dunan's email it sounds like you could create a
> mount unit and explicitly not set a conflict with the unmount target
> which would cause the filesystem to remain mounted at shutdown.  I have
> no idea what that would do to unmounting the root.

You'd have to deliberately jump thru at least two hoops in ordered to 
fail to have that Conflicts=umount.target applied, however, and thus it's 
extremely unlikely that it'd happen by accident.

1) You'd have to manually create the mount unit and place it in the 
appropriate override location, instead of using fstab and letting systemd-
fstab-generator create the mount unit dynamically at runtime, because the 
generator-created versions will all be using default dependencies 
(DefaultDependencies=yes being the default), which will add the 
conflicts /implicitly/ as part of those default deps (see the quote from 
the systemd.special (7) manpage in my previous post).

Note that while the conflicts line is not to be found in the dynamically 
runtime created from fstab mount units and thus isn't explicit, the fact 
that DefaultDependencies=no isn't explicitly set either, means those 
default dependencies apply, and they /implicitly/ include the 
conflicts=line.

So it's not explicit, but is never-the-less implicitly there and applies 
to any mount units dynamically generated from fstab.

Thus, to avoid it, you'd have to manually create the mount units and use 
them in place of fstab entries, and that's explicitly discouraged in the 
documentation -- use of fstab is recommended.

(No, I'm not supplying an explicit documentation reference for this as 
I'd have to look it up, but I do remember reading it while I was 
researching my switch to systemd, and pausing to explicitly make mental 
note of it, since it seemed such a contrast to the usual systemd pattern 
of uprooting the traditional tools and config methods in favor of its 
own, that would seem to be one of the big reasons so many people have 
such a strongly negative reaction to systemd.  Here, it was actually 
doing the opposite, encouraging people to continue to use the traditional 
fstab config, and discouraging use of the systemd-native config method, 
mount unit files.)

2) In your manually created mount unit, you'd have to explicitly set 
DefaultDependencies=no, because otherwise, it too would be subject to the 
implicit Conflicts=umount.target

Of course, jumping thru both those hoops is effectively impossible to do 
accidentally -- even if you decided without reading the documentation and 
noting that fstab usage was still encouraged, or read it and just decided 
to do native mount units anyway, the fact that none of the normal mount 
units you'd likely be using as examples in creation of your own, don't 
have an explicit DefaultDependiencies= line, means you'd have to learn 
about it from the documentation, in ordered to even know it was there to 
set to no.  And then you'd be doing it deliberately.

And if you did it deliberately for root... or for any other non-virtual 
filesystem, you would of course get to keep the pieces. =:^)

---
[1] Mount/umount at will:  In normal operating mode, anyway.  It doesn't 
always work that way early in the initr* or in other cases where systemd 
is in control but udev hasn't yet been run, tho I suspect the problem is 
limited to multi-device btrfs and any other multi-device filesystems that 
may be around, generally because the target triggering udev hasn't been 
run yet.  The reason is that the device units that a particular mount 
requires haven't been initiated yet, then.

The *extremely* puzzling to systemd newbies result being that attempting 
to mount a filesystem manually can exit success, but you go to actually 
use the mount and you'll find it not mounted, and it won't be listed in 
/proc/mounts or the like either.  What actually happens is that the mount 
executable does indeed make the correct kernel calls to do the mount, and 
the kernel does indeed do the mount, but systemd immediately umounts 
again, because the prerequisite device units haven't been initialized.  I 
suspect systemd automatically initializes the device fed in either on the 
mount commandline or from fstab, but isn't yet prepared to directly 
handle multi-device filesystems yet, and thus doesn't automatically 
activate the additional device units that it views as required by the 
filesystem, so even tho the kernel knows about them (due to a manual run 
of btrfs device scan) and can do the mount, systemd doesn't, and believes 
the mount-unit requirements aren't met and thus does the immediate umount.

I actually saw one mention of this on the btrfs list before I had a clue 
what was going on, I believe without anyone explaining the situation at 
the time, and later had it happen to me.  Only quite some time after 
having experienced it myself, did I realize why systemd was immediately 
umounting it -- because it hadn't seen the prerequisite devices yet.  And 
only now as I write this footnote, am I making the multi-device 
connection, which would explain why the problem isn't more widely seen 
among those using both systemd and btrfs, or on most other filesystems, 
since I now very strongly suspect a multi-device filesystem is a 
prerequisite to seeing the problem, as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman