Re: [gentoo-user] systemd mount - what on earth is it doing ...

[Rich Freeman]

On Sat, Sep 25, 2021 at 6:49 AM antlists <antlists@××××××××××××.uk> wrote:
>
> On 24/09/2021 21:30, Canek Peláez Valdés wrote:
>
> There's a lot of info about how to write a service file, but if you need
> to run before or after system service files, it's nowhere near so easy
> to find out Before=WHAT or After=WHAT :-)

So, I have a similar challenge because I use lizardfs and it can take
a while to initialize, and it isn't something systemd understands out
of the box.  (Plus it depends on a container running on the same host,
and those tend to run late, and other containers depend on the mount.)

I solved my issues with drop-ins and dependencies.

I did not create a mount unit for the mount.  I'm using fstab and its
generator to manage that.  However, I did use a drop-in so that the
automatically-created unit obtains the additional dependencies and
loads in the right order.  This requires using the right unit name as
created by the generator.

I set up dependencies for the mount unit so that it would run after
things that it needed.  I also set dependencies on services that use
the mount, so that they load later.  This wasn't something like home,
so I didn't apply those dependencies to a target.  However, if you
want to tie this into a standard target I suggest checking man
systemd.special or ask around.

> >
> >     So I created a systemd mount unit for /home, which only runs after
> >     dm-integrity. Great - I enabled it and it appeared to work!
> >
> >
> > You removed the /home entry from fstab, right?
> >
> mad it noauto, yes ...

That won't prevent the system from creating a unit for it - it just
won't be a dependency of local-fs.target.

I would suggest using only ONE of the following two approaches:1.
Entry in fstab plus a drop-in to modify its behavior with the same
name.
2. Custom mount unit with no entry in fstab at all (commented out is
fine, noauto is not).

It is possible you have more than one unit for the same mountpoint.
I'm not sure how exactly that behaves.  I'd just run "systemctl | grep
mount" and see what comes up - see if you have two apparent entries
for home.  If so one is probably from fstab and the other is probably
from your custom unit.  Unless they have the exact same name your unit
won't override the system one, and I'm actually not quite sure how
generators interact with unit overrides.  They seem to work fine with
drop-ins which is why I used this approach.

> > That should be home.mount. What does systemctl status home.mount says?
> >
> anthony@thewolery ~ $ systemctl status home.mount
> ● home.mount - Mount Home
>       Loaded: loaded (/etc/systemd/system/home.mount; disabled; vendor
> preset: disabled)
>
> >     So what on earth is going on, and more importantly, what am I
> >     misunderstanding or doing wrong. I would very much like to know why
> >     it's
> >     working, when I think it shouldn't be!
> >
> So fstab says noauto, home.mount is disabled, and /home is mounted on
> boot...
>

Using noauto only prevents it from being a dep for local-fs.target.
It doesn't prevent it from being mounted for some other reason.

I'd look at:
systemctl list-dependencies --reverse home.mount

Another command you might find useful is systemd-analyze dot.  The
direct output is actually readable, though intended to be converted
into a chart with graphviz using the hinted command it outputs.

If anything explicitly wants home.mount then it is going to get
mounted even if set to noauto.

Systemd is one of those things that is really capable, but you have to
grok a lot of concepts to make it dance for you, otherwise you'll feel
like you're the one being made to dance.  The internet is full of
one-liners now that it is so popular, but these often obfuscate how it
actually works.  It operates using a series of basic rules and once
you get how they're being strung together to make things work then it
is a lot easier to make it do what you expect.  Lennart's original
blog posts about systemd are very useful for this - maybe there are
some other good resources out there these days.

-- 
Rich