On Sun, 2021-06-13 at 11:44 -0400, Jon LaBadie wrote:
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
I did the same and it has made a big difference, i.e. I no longer have the very long delay waiting for usb-settle.
I still don't know why my external dock is being mounted at boot, but I can live with it for now.
poc