Re: [systemd-devel] _netdev for system root mount?
On Mon, 16 Mar 2020, Mantas Mikulėnas wrote: On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume wrote: On Fri, 13 Mar 2020, Alexander E. Patrakov wrote: > On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov wrote: > >> And what is the "official" way to prevent various units required by root >> mount from being stopped during shutdown? There could be arbitrarily >> deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...). > > https://systemd.io/ROOT_STORAGE_DAEMONS/ So, that means that the iscsi unit files in the running system are not designated and supported for system root, right? I've only used iSCSI for data volumes, but... how could the rootfs possibly be dependent on a process running *from the same rootfs*? I mean, the iSCSI or NBD daemons have to start from somewhere else *before* the rootfs is set up and mounted, don't they? If the rootfs is iSCSI-based or NBD-based, then I would expect the corresponding daemons to be started from the *initramfs*, meaning they wouldn't be managed as rootfs .service units in the first place -- and they wouldn't be stopped along with other .service units either. (Note that if your initramfs itself is systemd-based, then it has a completely separate set of units, with its own boot order and everything.) What about the network.service? I guess this should be also unsupported for the network device providing system root? network.service is a distro-specific addition. I don't know what it supports on your system. But in general, network configuration tools often have an option to leave an interface configured upon exit. For example systemd-network has KeepConfiguration=. Finally, can I also conclude that the _netdev parameter as an ordering constraint for the network block device is also not supported for system root? Same comment as above... how is systemd supposed to put other units before the rootfs, if they're started *from* the rootfs? I see the logic, thanks. Still, I think ths should better be documented, at least for the _netdev parameter. Best regards Thomas Blume SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] _netdev for system root mount?
On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume wrote: > On Fri, 13 Mar 2020, Alexander E. Patrakov wrote: > > > On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov > wrote: > > > >> And what is the "official" way to prevent various units required by root > >> mount from being stopped during shutdown? There could be arbitrarily > >> deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...). > > > > https://systemd.io/ROOT_STORAGE_DAEMONS/ > > So, that means that the iscsi unit files in the running system are not > designated and supported for system root, right? > I've only used iSCSI for data volumes, but... how could the rootfs possibly be dependent on a process running *from the same rootfs*? I mean, the iSCSI or NBD daemons have to start from somewhere else *before* the rootfs is set up and mounted, don't they? If the rootfs is iSCSI-based or NBD-based, then I would expect the corresponding daemons to be started from the *initramfs*, meaning they wouldn't be managed as rootfs .service units in the first place -- and they wouldn't be stopped along with other .service units either. (Note that if your initramfs itself is systemd-based, then it has a completely separate set of units, with its own boot order and everything.) > > What about the network.service? > I guess this should be also unsupported for the network device providing > system > root? > network.service is a distro-specific addition. I don't know what it supports on your system. But in general, network configuration tools often have an option to leave an interface configured upon exit. For example systemd-network has KeepConfiguration=. > > Finally, can I also conclude that the _netdev parameter as an ordering > constraint for the network block device is also not supported for system > root? > Same comment as above... how is systemd supposed to put other units before the rootfs, if they're started *from* the rootfs? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] _netdev for system root mount?
On Fri, 13 Mar 2020, Alexander E. Patrakov wrote: On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov wrote: And what is the "official" way to prevent various units required by root mount from being stopped during shutdown? There could be arbitrarily deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...). https://systemd.io/ROOT_STORAGE_DAEMONS/ So, that means that the iscsi unit files in the running system are not designated and supported for system root, right? What about the network.service? I guess this should be also unsupported for the network device providing system root? Finally, can I also conclude that the _netdev parameter as an ordering constraint for the network block device is also not supported for system root? Thanks Thomas SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] _netdev for system root mount?
On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov wrote: > And what is the "official" way to prevent various units required by root > mount from being stopped during shutdown? There could be arbitrarily > deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...). https://systemd.io/ROOT_STORAGE_DAEMONS/ -- Alexander E. Patrakov CV: http://pc.cd/PLz7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] _netdev for system root mount?
13.03.2020 11:19, Mantas Mikulėnas пишет: > On Fri, Mar 13, 2020 at 10:03 AM Thomas Blume wrote: > >> Hi, >> >> I have a SUSE SLES system where system root is provided via iscsi firmware >> (ibft). >> The installer automatically adds the _netdev parameter to the system root >> mount. >> The ordering when applying the _netdev parameter is documented as: >> >> --> >> Network mount units are ordered between remote-fs-pre.target and >> remote-fs.target, instead of local-fs-pre.target and local-fs.target. They >> also >> pull in network-online.target and are ordered after it and network.target. >> --< >> >> On system start, I can see this: >> >> --> >> Mär 12 16:38:11 install systemd[1]: >> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device: >> Dependency Before=network-online.target ignored (.device units cannot be >> del> >> Mär 12 16:38:11 install systemd[1]: >> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device: >> Dependency Before=network.target ignored (.device units cannot be delayed) >> Mär 12 16:38:11 install systemd[1]: >> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency >> Before=network-online.target ignored (.device units cannot be delayed) >> Mär 12 16:38:11 install systemd[1]: >> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network.target >> ignored (.device units cannot be delayed) >> --< >> >> Which looks like _netdev becomes almost a noop. >> The only effect I can see afterwards is that the system root mount gets >> ordered >> below remote-fs.target: >> >> > Somehow the 'cannot be delayed' message does not make sense with Before=. > > But it feels like the dependency itself is backwards, too, it should be > *After=* network.target... At least I see the regular > systemd-fstab-generator adds After=, which makes more sense, but it still > triggers the same message. > This is just confusing message, current systemd should print After=network.target here (see commit c80a9a33d04fb4381327a69ce929c94a9f1d0e6c). > I guess there's a bug in there somewhere but I'm not sure where. > > >> >> ● └─remote-fs.target >> ● ├─-.mount >> ● ├─boot-efi.mount >> ● └─iscsi.service >> >> But this is also a noop, because system root is already mounted in the >> initrd >> and has no more relevance after switch root. >> It could be even dangerous, because on shutdown the system root mount >> might be >> attempted to stop before the system is switching back to the initrd. >> > > AFAIK the root mount is never stopped (and has the 'perpetual' flag set). I > don't think it would even be *possible* to do so because pid1 itself is > being executed from there, as well as there's still other filesystems > (/run, /dev) mounted on top of it. (Which is the entire point of switching > back to the shutdown-initramfs.) > > Either way – stopping a mount literally just unmounts the filesystem (which > is supposed to be a safe operation). I'd probably be more worried about > iscsi.service, since the blockdev losing connection *before* its fs is > unmounted is actually the dangerous part... > And what is the "official" way to prevent various units required by root mount from being stopped during shutdown? There could be arbitrarily deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...). And no, DefaultDepedencies=no is not an answer because it just shifts the question to "how to add this directive to one instance only". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] _netdev for system root mount?
On Fri, Mar 13, 2020 at 10:03 AM Thomas Blume wrote: > Hi, > > I have a SUSE SLES system where system root is provided via iscsi firmware > (ibft). > The installer automatically adds the _netdev parameter to the system root > mount. > The ordering when applying the _netdev parameter is documented as: > > --> > Network mount units are ordered between remote-fs-pre.target and > remote-fs.target, instead of local-fs-pre.target and local-fs.target. They > also > pull in network-online.target and are ordered after it and network.target. > --< > > On system start, I can see this: > > --> > Mär 12 16:38:11 install systemd[1]: > dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device: > Dependency Before=network-online.target ignored (.device units cannot be > del> > Mär 12 16:38:11 install systemd[1]: > dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device: > Dependency Before=network.target ignored (.device units cannot be delayed) > Mär 12 16:38:11 install systemd[1]: > dev-disk-by\x2duuid-515E\x2d433F.device: Dependency > Before=network-online.target ignored (.device units cannot be delayed) > Mär 12 16:38:11 install systemd[1]: > dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network.target > ignored (.device units cannot be delayed) > --< > > Which looks like _netdev becomes almost a noop. > The only effect I can see afterwards is that the system root mount gets > ordered > below remote-fs.target: > > Somehow the 'cannot be delayed' message does not make sense with Before=. But it feels like the dependency itself is backwards, too, it should be *After=* network.target... At least I see the regular systemd-fstab-generator adds After=, which makes more sense, but it still triggers the same message. I guess there's a bug in there somewhere but I'm not sure where. > > ● └─remote-fs.target > ● ├─-.mount > ● ├─boot-efi.mount > ● └─iscsi.service > > But this is also a noop, because system root is already mounted in the > initrd > and has no more relevance after switch root. > It could be even dangerous, because on shutdown the system root mount > might be > attempted to stop before the system is switching back to the initrd. > AFAIK the root mount is never stopped (and has the 'perpetual' flag set). I don't think it would even be *possible* to do so because pid1 itself is being executed from there, as well as there's still other filesystems (/run, /dev) mounted on top of it. (Which is the entire point of switching back to the shutdown-initramfs.) Either way – stopping a mount literally just unmounts the filesystem (which is supposed to be a safe operation). I'd probably be more worried about iscsi.service, since the blockdev losing connection *before* its fs is unmounted is actually the dangerous part... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] _netdev for system root mount?
Hi, I have a SUSE SLES system where system root is provided via iscsi firmware (ibft). The installer automatically adds the _netdev parameter to the system root mount. The ordering when applying the _netdev parameter is documented as: --> Network mount units are ordered between remote-fs-pre.target and remote-fs.target, instead of local-fs-pre.target and local-fs.target. They also pull in network-online.target and are ordered after it and network.target. --< On system start, I can see this: --> Mär 12 16:38:11 install systemd[1]: dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device: Dependency Before=network-online.target ignored (.device units cannot be del> Mär 12 16:38:11 install systemd[1]: dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device: Dependency Before=network.target ignored (.device units cannot be delayed) Mär 12 16:38:11 install systemd[1]: dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network-online.target ignored (.device units cannot be delayed) Mär 12 16:38:11 install systemd[1]: dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network.target ignored (.device units cannot be delayed) --< Which looks like _netdev becomes almost a noop. The only effect I can see afterwards is that the system root mount gets ordered below remote-fs.target: ● └─remote-fs.target ● ├─-.mount ● ├─boot-efi.mount ● └─iscsi.service But this is also a noop, because system root is already mounted in the initrd and has no more relevance after switch root. It could be even dangerous, because on shutdown the system root mount might be attempted to stop before the system is switching back to the initrd. Is _netdev applicable for the system root mount at all? Regards Thomas BLume SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
