0

I wanted to have a custom service unit depend on a mounting point of a remote filesystem CVMFS. The remote filesystem has a strange setup in systemd which I do not completely understand. I have made a simple workaround with an intermediate service unit, so it works fine. But I would like to understand how the units of the remote filesystem work, in order to be aware of such behavior in systemd.

Here is the mounting point unit of the remote filesystem:

$ systemctl status cvmfs-sft.cern.ch.mount * cvmfs-sft.cern.ch.mount Loaded: loaded Active: active (mounted) since Wed 2024-07-31 23:31:49 CEST; 1min 32s ago Until: Wed 2024-07-31 23:31:49 CEST; 1min 32s ago Where: /cvmfs/sft.cern.ch What: cvmfs2

It does not list a unit file. The unit must have been created somehow dynamically. So, when I add a Requires=cvmfs-sft.cern.ch.mount to my unit, it fails during the Linux boot up with this:

localhost systemd[1]: Failed to start A one shot script ... <hostname> systemd[1]: ....service: Failed to schedule restart job: Unit cvmfs-sft.cern.ch.mount not found.

However, if I launch my unit after the boot, it comes up fine. I.e. the Requires=cvmfs-sft.cern.ch.mount dependency works fine when I log in as a normal user, the server has reached the multiuser target, the cvmfs is mounted and that unit cvmfs-sft.cern.ch.mount is active.

What I expected is to have actual unit files for the cvmfs mounting points. The remote filesystem would take its time to mount those mounting points, and my units would proceed from there.

According to the CVMFS documentation, what really manages this filesystem is this autofs.service. The autofs service runs mount points like this:

$ systemctl status autofs * autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled; preset: disabled) Drop-In: /usr/lib/systemd/system/autofs.service.d `-50-cvmfs.conf ... CGroup: /system.slice/autofs.service |-3405 /usr/bin/cvmfs2 ... sft.cern.ch /cvmfs/sft.cern.ch ...

What I want to ask is what can create such units without unit files in systemd? If I have an init.d script, systemd always translates it into an actual unit file, doesn't it? In this particular case, the unit status says What: cvmfs2. Does it mean that cvmfs2 use the following feature of systemd.mount?

$ man systemd.mount ... DESCRIPTION ... The systemd-mount(1) command allows creating .mount and .automount units dynamically and transiently from the command line.

I guess you need this transient behavior for mounting points, in the case when the user plugs a USB drive in the computer etc. But can other unit types be created transiently, i.e. on the fly without a unit file?

Is there a good way to find out what launched such a transient unit? In my case, the unit dependencies don't tell me anything:

$ sudo systemctl list-dependencies cvmfs-sft.cern.ch.mount cvmfs-sft.cern.ch.mount * |--.mount * `-system.slice $ sudo systemctl list-dependencies --reverse cvmfs-sft.cern.ch.mount cvmfs-sft.cern.ch.mount

Is there some other systemctl command that could tell you something more about the provenance of a transient unit like this?

Improve this question

1 Answer 1

Reset to default
1

What I want to ask is what can create such units without unit files in systemd?

Systemd itself, technically.

Much like systemd generates .device unit representations for devices that are seen by libudev, it also generates .mount unit representations for every actual mount that is visible in its /proc/self/mounts, as well as .swap unit representations for every active swap device.

But those are not "transient units" in the way systemd uses that term. A transient unit originates from systemd – it is created via API (e.g. by calling systemd-mount or systemd-run) and usually exists as a temporary file in /run/systemd – whereas these units you see are not that. They're representations of some state that originates from outside systemd's control; in this case, they represent mounts that were done by programs directly talking to the kernel without involving systemd.

Therefore,

Is there a good way to find out what launched such a transient unit? In my case, the unit dependencies don't tell me anything:

The unit was not launched at all. Its existence is the effect, not the cause, of the actual mount.

If I have an init.d script, systemd always translates it into an actual unit file, doesn't it?

Yes, although in all current versions, that translation is not done by systemd proper (i.e. not by the service manager); it's done by a separate "generator" that literally writes out .service files in /run/systemd based off the init.d scripts.

Only very old systemd versions actually created virtual in-memory .service units representing init.d scripts, but that was removed 10 years ago. (yes, if you're running systemd v209, that's ten years old by now!)

In this particular case, the unit status says What: cvmfs2. Does it mean that cvmfs2 use the following feature of systemd.mount?

No, it means that the string cvmfs2 was specified as the "source" field of the mount. It's what you would see in the "SOURCE" column of mount or findmnt.

According to the CVMFS documentation, what really manages this filesystem is this autofs.service. The autofs service runs mount points like this:

That means you probably don't need to depend on the individual mounts – it should be enough to depend on autofs.service as a whole. Yes, it somewhat throws off the usual systemd logic, but it should work assuming autofs does the job it's meant to do.

(I can't think offhand of a way to define a mount dependency that would wait for that mount to appear. I would have expected it to be Requires+After – in fact, you want to have the After= in any case – but it only seems to work for devices and not for mounts.)

Improve this answer
1
  • Thanks! "The unit was not launched at all. Its existence is the effect, not the cause, of the actual mount." - I did not expect this. I think having Requires+After on autofs.service was not enough, so I ended up adding a one-shot service after autofs with a bash script: the script tries to ls a mounted directory a few times, with delays in between. I guess, the script could also wait for some event, like with inotifywait and a timeout. Commented Sep 30, 2024 at 14:44

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.