[systemd-devel] Suppressing automounting

Dale R. Worley worley at alum.mit.edu
Thu Sep 4 15:32:20 PDT 2014


> From: Andrei Borzenkov <arvidjaar at gmail.com>

> bor at opensuse:~/src/systemd> systemctl show boot.mount  -p WantedBy --no-pager
> WantedBy=dev-sda1.device
> 
> Which has the effect that if device was not present at boot but appears
> later, the very appearance of device triggers start of mount unit -
> filesystem gets mounted.
> 
> And yes, this makes semantic very different from
> traditional /etc/fstab. And I'm not sure it has to do it by default ...
> honestly, I'm not sure it has to do it at all. I think about situation
> where I have persistent device names (SAN, iSCSI, LVM) and need to do
> maintenance which causes device nodes disappear and appear again. I
> definitely do not want any filesystem to be suddenly mounted in this
> case until I have finished my tasks.
> 
> And of course it is not documented anywhere.

I admit that I haven't studied systemd enough to understand the
significance of WantedBy.  My understanding is that systemd performs a
series of units, with dependencies showing which units must finish
before other units start.  But it appears that boot.mount does not
represent a particular task, but some sort of generic task that is
executed multiple times, one for each ".device" unit. -- Or is "boot"
the name of the mountpoint, and "boot.mount" only represents the work
for mounting /dev/sd1 as /boot?

However, if I wanted to add an option that means "give up on
attempting to mount this device after xx seconds", what would be a
good way to organize it, given the architecture of systemd?  It
appears that there is a general mechanism for inserting information
for systemd into the "options" part of an /etc/fstab line, so
presumably the indication for the option would be placed there.

In my "Store.mount" file, I see no indication of an executable which
implements the unit.  What is the code which implements it?  Would it
be possible for that code to determine how long it has been?

Dale


More information about the systemd-devel mailing list