[systemd-devel] Problem with shutdown and automount units
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. [1] http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/98systemd/dracut-shutdown.service ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with shutdown and automount units
On 08.12.2014 14:21, Harald Hoyer wrote: On 08.12.2014 13:28, Dave Reisner wrote: On Dec 8, 2014 5:54 AM, Harald Hoyer har...@redhat.com mailto:har...@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. In mkinitcpio, we implemented a feature to build directly into /run, rather than extracting any existing initramfs. Neat, might be a solution to think of. While I can workaround it, the systemd problem is still there. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with shutdown and automount units
On Mon, 08.12.14 11:54, Harald Hoyer (har...@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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with shutdown and automount units
On 08.12.2014 15:24, Lennart Poettering wrote: On Mon, 08.12.14 11:54, Harald Hoyer (har...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with shutdown and automount units
On Mon, 08.12.14 15:34, Harald Hoyer (harald.ho...@gmail.com) wrote: On 08.12.2014 15:24, Lennart Poettering wrote: On Mon, 08.12.14 11:54, Harald Hoyer (har...@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 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
