[systemd-devel] Suppressing automounting

Andrei Borzenkov arvidjaar at gmail.com
Wed Aug 27 19:50:06 PDT 2014


В Thu, 28 Aug 2014 00:31:49 +0300
Mantas Mikulėnas <grawity at gmail.com> пишет:

> On Aug 27, 2014 10:03 PM, "Dale R. Worley" <worley at alum.mit.edu> wrote:
> >
> > > From: Thomas Suckow <thomas.suckow at pnnl.gov>
> > >
> > > >> From: Lennart Poettering <lennart at poettering.net>
> > > >
> > > >> Note that a concept of "mount at boot if it is there, otherwise
> don't"
> > > >> cannot work.
> > > >
> > > > It worked until a week or two ago.  I want it back.
> > > >
> > > > I'm sure you're right that in the abstract, it cannot be made to
> > > > work.  But that isn't the problem I'm facing.
> > >
> > > It seems that a workaround could be to not put the volume in fstab
> > > and add a unit to the startup that would mount it if present. If you
> > > wanted to mount it later, you could manually start the unit again.
> >
> > I'd rather adjust systemd and leave fstab stable than vice-versa.
> >
> > Here's an interesting fact:  What systemd does (in this situation)
> > isn't true automounting; rather it waits for the *first* time the
> > device/volume becomes available, and then mounts it.  Any later
> > attachments of the volume do not cause mounting (until the next
> > reboot).
> >

Well, that's how /etc/fstab always behaved, right? Anything in there is
"automounted" just once, when system boots. Later you have to manually
do it.

> > But at this point, I only need to investigate the issue.  The
> > documentation I've managed to find about systemd is rather abstract,
> > there's no map between specific bits of functionality and the files
> > that control them.
> >
> > My understanding is that everything systemd does is controlled by
> > "units".  In this case, entries in fstab cause the creation of units
> > based on a "template".  If you could point me to the template file in
> > question, it would probably point me to all of the things I need to
> > investigate.
> 
> For fstab, the units are created by a 'generator'
> (systemd-fstab-generator), which writes them under /run/systemd/generator
> every time the configuration is reloaded.
> 
> I'm not at my PC right now so I cannot check, but I /do/ remember someone
> mentioning that if a fstab entry has the 'auto' option, then the generator
> also symlinks the corresponding .mount unit under <devpath>.device.wants/
> (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to
> be triggered *every* time that device appears on the system.
> 
> That is, in addition to local-fs.target triggering foo.mount and waiting
> for bar.device one time only (as you describe), it makes bar.device itself
> trigger foo.mount every time as well.
> 

Hmm ... I'm not sure where this dependency comes from, but yes, it is
there

Requires=systemd-fsck at dev-sda1.service -.mount
Wants=system.slice
RequiredBy=local-fs.target systemd-sysctl.service
WantedBy=dev-sda1.device
Before=local-fs.target systemd-sysctl.service umount.target
After=systemd-journald.socket dev-sda1.device systemd-fsck at dev-sda1.service local-fs-pre.target system.slice -.mount

This looks like one of those implicit dependencies that are not
documented anywhere ...


More information about the systemd-devel mailing list