On Mon, 08.12.14 15:34, Harald Hoyer ([email protected]) wrote: > On 08.12.2014 15:24, Lennart Poettering wrote: > > On Mon, 08.12.14 11:54, Harald Hoyer ([email protected]) 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 late... 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 automounts... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
