2

I'm tired of services such as snapd and blueman-mechanism delaying my boot by upwards of 10, 20 seconds each on Ubuntu 20.04.4.

While the solution for snapd was simply to apt purge it, I don't like the idea of crippling my machine's hardware capabilities, as I've been considering getting a bluetooth headset or keyboard recently—that's just not a reasonable workaround.

It it possible to leave certain services enabled, but remove them from the boot-wait chain?

Even on my laptop, there's no reason that the system should, for example, block me from logging in for an additional 4.068s while waiting for wpa_supplicant.service to start up, much less on a desktop (which I pulled that particular number from in this instance—it's highlighted in deep red in the SVG plot) with no currently-active Wi-Fi connections.

Right now, it seems the options are

  • Just cope / buy more hardware upgrades (that will be obsolete in a few years anyway)
  • Start disabling parts of the system that I might legitimately need later as a workaround for inappropriate boot dependencies

Is there any way to avoid both of these depressing options and simply remove certain services from the boot-wait chain (but without disabling them)? I'd much rather have networkd-dispatcher.service (10.093s) keep chugging while I'm typing my password and logging in.

For some services, such as NetworkManager-wait-online.service (9.897s), disabling them is generally viable for user-facing desktops… but I'm interested in fixing the problem—safely transplanting services out of the boot wait chain—rather than continuing to play whack-a-mole with unique components and hoping I don't break something. The only things I need ready before I log in are the filesystem check and the display and input drivers. Everything else can share CPU with Firefox.

Zanna
  • 70,465
JamesTheAwesomeDude
  • 1,985
  • We've had multi-core CPUs for how many years now? Send that stuff to another thread! Even my backup machine's Pentium 4 has hyperthreading. Why have a pre-empting kernel if we're not going to use it? – JamesTheAwesomeDude Mar 18 '22 at 06:32
  • Some preliminary analysis shows a few highly problematic chains: (1) lightdm.service is After systemd-user-sessions.service which is After network.target; (2) graphical.target is After multi-user.target which is After wpa_supplicant.service NetworkManager.service systemd-networkd.service and Wants blueman-mechanism.service – JamesTheAwesomeDude Mar 19 '22 at 13:52
  • Annoyingly, systemd does not let one override these relationships easily: “Dependencies (After=, etc.) cannot be reset to an empty list [in overrides]… If you want to remove dependencies, you have to override the entire unit.” – JamesTheAwesomeDude Mar 19 '22 at 13:56

0 Answers0