On 13/06/2021 07:36, Samuel Sieb wrote:
Yes, but I would think there is still a period of time associated with calling the service, discovering the link to /dev/null and then understanding the service has completed.
It isn't as if the service file no longer exits.
"impossible to start them" and "prohibits all kinds of activation of the unit"
And from the description of what the "masked" status means: Completely disabled, so that any start operation on it fails.
But as shown from the quoted log lines, "udevadm" is definitely getting called still.
Did you miss this line? "udevadm settle" is still getting called according to that log, so the original service file is still getting run for some reason. From your earlier message, 542ms is still kind of long, but not unreasonable. Do you still get the message from udevadm in the log, though?
No, I didn't. And, yes, it is my log too.
Isn't nm-initrd.service added to the initramfs?
So, that contains
Wants=systemd-udev-settle.service After=systemd-udev-settle.service After=dracut-cmdline.service Before=network.target
So, it would still be referenced, attempted to be started, but and then it takes a bit of time to determine not to use the service file in /lib/systemd/system but the one in /etc/systemd/system read the "commands" from /dev/null and then exit.
since /usr/lib/dracut/modules.d/35network-manager/nm-initrd.service contains that service file wouldn't it make sense to request that changes are made to dracut-network which provides that?