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