On Mon, 16 Mar 2020, Mantas Mikulėnas wrote:
On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume <thomas.bl...@suse.com> wrote:
On Fri, 13 Mar 2020, Alexander E. Patrakov wrote:
> On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov <arvidj...@gmail.com>
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
