On Mon, 16 Mar 2020, Mantas Mikulėnas wrote:
On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume <Thomas.Blume@xxxxxxxx> wrote:
On Fri, 13 Mar 2020, Alexander E. Patrakov wrote:
> On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov <arvidjaar@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
