Re: Long wait for start job

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-06-12 4:14 p.m., Ed Greshko wrote:
On 13/06/2021 07:06, Samuel Sieb wrote:
On 2021-06-12 3:46 p.m., Patrick O'Callaghan wrote:
On Sat, 2021-06-12 at 14:43 -0700, Samuel Sieb wrote:
On 2021-06-12 10:19 a.m., Tom Horsley wrote:
On Sat, 12 Jun 2021 10:44:19 -0600
Joe Zeff wrote:

According to https://github.com/openzfs/zfs/issues/10891 has been
depricated since last year.  Disable and mask it and that should
fix
your issue.

It is listed as a "static" service on my system. Can those be
disabled or masked?

It can't be disabled, but it can be masked.

I've masked it and rebooted. Makes no difference to boot time in my
case.

Jun 13 00:13:59 Bree systemd[1]: Starting Wait for udev To Complete Device Initialization... Jun 13 00:13:59 Bree udevadm[413]: systemd-udev-settle.service is deprecated. Please fix nm-initrd.service not to pull it in. Jun 13 00:14:29 Bree systemd[1]: Finished Wait for udev To Complete Device Initialization. Jun 13 00:14:30 Bree systemd[1]: systemd-udev-settle.service: Deactivated successfully. Jun 13 00:14:30 Bree systemd[1]: Stopped Wait for udev To Complete Device Initialization.

That is weird.  It shouldn't get run if it's masked.  Is the service file in /etc/systemd/system by any chance?

Since it is being "pulled in" by other services I think you may expect to see this.

From the systemctl man page describing the "mask" command:
Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the unit, including enablement and manual activation.

"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.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux