[systemd-devel] Suppressing automounting

[Colin Guthrie]

Dale R. Worley wrote on 10/09/14 20:56:
>> From: Mantas Mikulėnas <grawity at gmail.com>
> 
>>> What I was thinking of is, what is the program that reads (directly or
>>> indirectly) the Store.mount file and from that decides exactly how to
>>> call mount(8), and when to call it?
>>
>> It's systemd itself (pid 1).
>>
>>> My guess was that the name of this program would be listed *in* the
>>> *.mount file, but that does not appear to be so.
>>
>> That would not make any sense: if the program wasn't running yet, how
>> could it possibly start itself in order to read the .mount file which
>> just tells it to start itself?
> 
> In many systems, there's a framework program that reads a lot of
> control files which describe the bits of work to be done.  The
> framework program figures out the sequencing and dependencies of the
> various bits of work, while there are separate programs that *execute*
> the bits of work.  And the names of the execution programs are not
> hard-coded within the framework program, they are specified in the
> control files.  That sort of structure makes the framework program
> simpler, and enforces a defined interface between the framework
> program and the execution programs.  It also makes it easy to add new
> execution programs without changing the framework program.

I'm maybe missing something, but in the case of mount units, isn't that
framework program mount(8)?

It has a mechanism for parsing default options that apply to all mounts
and then calling out to the appropriate, filesystem specific mount
program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.)
if appropriate.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/