On Aug 27, 2014 10:03 PM, "Dale R. Worley" <wor...@alum.mit.edu> wrote:
>
> > From: Thomas Suckow <thomas.suc...@pnnl.gov>
> >
> > >> From: Lennart Poettering <lenn...@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).
>
> 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.

-- 
Mantas Mikulėnas <graw...@gmail.com>
// sent from phone
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to