On Sat, Sep 25, 2021 at 6:49 AM antlists <[email protected]> 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
