On Sun, Jun 13, 2021 at 09:02:49AM +0800, Ed Greshko wrote:
On 13/06/2021 08:41, Samuel Sieb wrote:
So that gave me the clue that led to the real problem. The service is included in the initrd and masking it on the system doesn't change that. Even re-creating the initrd with dracut after masking didn't change anything.
And also the nm-initrd.service file is in dracut, so you would have to modify it there (not the system one) to change this.
FWIW, I had a VM which needed a kernel update.
Prior to the update it had references to systemd-udev-settle.service in the logs.
I edited /usr/lib/dracut/modules.d/35network-manager/nm-initrd.service to have
DefaultDependencies=no #Wants=systemd-udev-settle.service #After=systemd-udev-settle.service After=dracut-cmdline.service
And I installed the latest kernel.
Now....
[egreshko@f34x ~]$ systemctl status systemd-udev-settle.service ○ systemd-udev-settle.service Loaded: masked (Reason: Unit systemd-udev-settle.service is masked.) Active: inactive (dead)
And nothing in the logs about systemd-udev-settle
Just a data point, all with the same kernel, 5.12.9-300.fc34:
My reboot times were over 2 minutes. Systemd-analyze blame showed systemd-udev-settle.service taking 2+ min. I then tried to disable the unit and mask it. Next I commented the lines noted above.
Unit state Appears in systemd-analyze blame critical-chain
unchanged Y Y disabled&masked Y N disabled&masked + N N nm-initrd unit edited
That repeats what others observed. But the reboot time change was dramatic. Here are the top lines of systemd-analyze critical-chain for the last two reboots above:
graphical.target @2min 14.541s
graphical.target @10.072s