On 6/12/21 4:29 PM, Ed Greshko wrote:
On 13/06/2021 07:22, Samuel Sieb wrote:
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.
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.
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?
_______________________________________________
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
