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?
--
Remind me to ignore comments which aren't germane to the thread.