Re: [systemd-devel] Unmountable mounts and systemd-fsck@.service conflicting with shutdown.target
It is a call to systemd-mount done from initramfs. It ends up in /run/systemd/transient and survives the root switch. The generated unit contains Requires=systemd-fsck@service. Is the conflict on shutdown.target to make shutdown kill fsck if it is running? Generated systemd-cryptsetup@.service units have "DefaultDependencies=no" and no conflict on shutdown. Maybe this is missing then. "cryptsetup attach" might be running. On Fri, Jan 6, 2023 at 1:34 PM Lennart Poettering wrote: > On Do, 05.01.23 14:18, Valentin David (valentin.da...@canonical.com) > wrote: > > > Hello, > > > > In Ubuntu Core, we have some mounts that cannot be unmounted until we > have > > switched root. > > > > To simplify, this looks like that: > > > > / mounts a ro loop devices backed by /some/disk/some/path/image.img > > /some/disk mounts a block device (let's say /dev/some-block0p1) > > > > In this case, /some/disk cannot be unmounted. > > > > We do not want to lazily unmount, we cannot get errors if something > fails. > > (Unless we had a lazy unmount that would only work when read-only) > > > > We do remount /some/disk read-only on shutdown. And in the shutdown > > intramfs, we unmount /oldroot/some/disk. > > > > However, we get an error message with systemd trying to unmount it. While > > functionally, it does not matter, it is still very problematic to have > > error messages. > > > > Using `DefaultDependencies=no` is not enough. I have tried to be clever > and > > add some-disk.mount to shutdown.target.wants so it would not try to > unmount > > it. But systemd got confused with conflicts and randomly kills stop jobs > > until there is no conflict. > > > > Debugging it, I have found that this is because some-disk.mount depends > on > > systemd-fsck@some\x2dblock0p1.service. And systemd-fsck@.service > conflicts > > with shutdown.target. > > > > I wonder if having conflict on shutdown.target really needed. Could we > > remove it? (And also add DefaultDepenencies=no to > > system-systemd\x2dfsck.slice) With this, mounts with > DefaultDependencie=no > > do not get unmounted as part of shutdown.target. (They do during > > systemd-shutdown) > > hmm, so we generally want system services to go away before > shutdown. This is a very special case though. I wonder if we can just > override systemd-fsck@….service for that specific case? > > How are those mounts established? i.e. by which unit is the > systemd-fsck@.service instance pulled in? and how was that configured? > fstab? ubuntu-own code? > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] Unmountable mounts and systemd-fsck@.service conflicting with shutdown.target
On Do, 05.01.23 14:18, Valentin David (valentin.da...@canonical.com) wrote: > Hello, > > In Ubuntu Core, we have some mounts that cannot be unmounted until we have > switched root. > > To simplify, this looks like that: > > / mounts a ro loop devices backed by /some/disk/some/path/image.img > /some/disk mounts a block device (let's say /dev/some-block0p1) > > In this case, /some/disk cannot be unmounted. > > We do not want to lazily unmount, we cannot get errors if something fails. > (Unless we had a lazy unmount that would only work when read-only) > > We do remount /some/disk read-only on shutdown. And in the shutdown > intramfs, we unmount /oldroot/some/disk. > > However, we get an error message with systemd trying to unmount it. While > functionally, it does not matter, it is still very problematic to have > error messages. > > Using `DefaultDependencies=no` is not enough. I have tried to be clever and > add some-disk.mount to shutdown.target.wants so it would not try to unmount > it. But systemd got confused with conflicts and randomly kills stop jobs > until there is no conflict. > > Debugging it, I have found that this is because some-disk.mount depends on > systemd-fsck@some\x2dblock0p1.service. And systemd-fsck@.service conflicts > with shutdown.target. > > I wonder if having conflict on shutdown.target really needed. Could we > remove it? (And also add DefaultDepenencies=no to > system-systemd\x2dfsck.slice) With this, mounts with DefaultDependencie=no > do not get unmounted as part of shutdown.target. (They do during > systemd-shutdown) hmm, so we generally want system services to go away before shutdown. This is a very special case though. I wonder if we can just override systemd-fsck@….service for that specific case? How are those mounts established? i.e. by which unit is the systemd-fsck@.service instance pulled in? and how was that configured? fstab? ubuntu-own code? Lennart -- Lennart Poettering, Berlin
[systemd-devel] Unmountable mounts and systemd-fsck@.service conflicting with shutdown.target
Hello, In Ubuntu Core, we have some mounts that cannot be unmounted until we have switched root. To simplify, this looks like that: / mounts a ro loop devices backed by /some/disk/some/path/image.img /some/disk mounts a block device (let's say /dev/some-block0p1) In this case, /some/disk cannot be unmounted. We do not want to lazily unmount, we cannot get errors if something fails. (Unless we had a lazy unmount that would only work when read-only) We do remount /some/disk read-only on shutdown. And in the shutdown intramfs, we unmount /oldroot/some/disk. However, we get an error message with systemd trying to unmount it. While functionally, it does not matter, it is still very problematic to have error messages. Using `DefaultDependencies=no` is not enough. I have tried to be clever and add some-disk.mount to shutdown.target.wants so it would not try to unmount it. But systemd got confused with conflicts and randomly kills stop jobs until there is no conflict. Debugging it, I have found that this is because some-disk.mount depends on systemd-fsck@some\x2dblock0p1.service. And systemd-fsck@.service conflicts with shutdown.target. I wonder if having conflict on shutdown.target really needed. Could we remove it? (And also add DefaultDepenencies=no to system-systemd\x2dfsck.slice) With this, mounts with DefaultDependencie=no do not get unmounted as part of shutdown.target. (They do during systemd-shutdown)
