On Mon, Jun 29, 2020 at 2:58 PM Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> We might need to explicitly disable systemd-udev-settle.service
> during the system upgrade to turn it off?
Doesn't work... I tried 'systemctl disable systemd-udev-settle.service'
and rebooted again, and it's still running. I tried 'systemd-analyze
plot' and I see it takes 11 seconds during boot! I think the culprit is
dmraid-activation.service (not dmraid.service). Did you get the name of
the service wrong in the change proposal, or have I misunderstood?
Unrelated: looking at my systemd-analyze plot, other startup time
offenders are NetworkManager-wait-online.service (9.5 seconds, seems
egregious, I wonder why this is necessary?) and grand prize winner
abrtd.service (requiring an amazing 30 seconds!)
Many activate and run in parallel, including
NetworkManager-wait-online, and don't directly contribute to startup
delays. That one should really just be waiting for all the network
configuration to really happen before trying things that depend on the
network: e.g. NFS and maybe some kind of network login. Some services
can stuck much longer if they try to connect before there's a
connection available.
But yeah all of the enabled by default services probably need a review
for F33 to make sure they're intentionally enabled. /me not a fan of
startup delays, I really wanna be under 10s. Right now I'm at 19s and
that's on NVMe with no external devices or services to connect to.
--
Chris Murphy