[systemd-devel] Problem with shutdown and automount units

Lennart Poettering lennart at poettering.net
Mon Dec 8 06:39:09 PST 2014

On Mon, 08.12.14 15:34, Harald Hoyer (harald.hoyer at gmail.com) wrote:

> On 08.12.2014 15:24, Lennart Poettering wrote:
> > On Mon, 08.12.14 11:54, Harald Hoyer (harald at redhat.com) wrote:
> > 
> >> Today I changed the dracut-shutdown.service [1] to do its job on ExecStop,
> >> This was done, to order the action before local-fs.target is stopped. Mainly to
> >> run before boot.automount / boot.mount is stopped.
> >>
> >> Works so far, but, if boot was _not_ yet automounted on shutdown, the
> >> boot.automount is blocked to mount in the transition to the shutdown.target.
> >>
> >> So, if any ExecStop relies on a path, which is normally automounted, but not
> >> yet used, it fails on execution.
> > 
> > Yes, this is correct, we refuse new triggers of busnames, sockets or
> > automount units if we area going down, so that the shutdown operation
> > is not reversed. This is known behaviour.
> > 
> > If you know that ExecStop= needs some resource, I'd recommend pulling
> > in the unit for it explicitly with Wants=, so that it is pulled in
> > already during start. In you case, pull in the .mount unit with Wants=
> > in [Unit] and all should be good?
> > 
> > Lennart
> > 
> That would defeat the purpose of automount, wouldn't it?
> Are you sure, you want to have all units Wants=var.mount Wants=boot.mount
> Wants=opt.mount Want=srv.mount, which need /var /boot /opt or /srv in ExecStop?
> I know, this does not happen that often, that ExecStart does not need the very
> same... just asking.

Well, if we have to trigger the automounts anyway during shutdown it
doesn't really matter when we trigger them: early on, or only very

Automounts are useful for to things: (a) parallelizing start-up and
(b) avoiding triggering automounts which aren't used. Now, (a) is
unaffected by pulling in the .mount unit from your shutdown
service. And (b) doesn't apply if you need to access the directory
anyway... Hence I don't see why this would defeat the purpose of


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list