How to enable systemd's service without waiting?

kravecm · 2015-01-13 14:40:43

I'm trying to make fastest boot possible. However, huge impact on my boot time has NetworkManager. Is there any way to enable NetworkManager to be run at startup, but not as dependency of multi-user.target?

I've also asked question on unix exchange., where I provided more details. But such site seems pretty dead compared to stackoverlow. So I'm posting on it also Arch Linux Forums.

http://unix.stackexchange.com/questions … ut-waiting

Trilby · 2015-01-13 15:17:10

I think you're misunderstanding how targets work. You might very well be in your WM/DE opening/editing documents well before the multi-user target is actually complete.

Do you want your boot up to be more efficient for you to be able to start working, or do you just want to fudge the numbers of systemd-analyze?

EDIT: as an example:

Startup finished in 4.535s (kernel) + 1.303s (initrd) + 5.234s (userspace) = 11.072s

Yet, I'm in my WM working at ~1 second into userspace:

multi-user.target @5.234s
└─swifer.service @984ms +4.248s
  └─basic.target @961ms
    └─sockets.target @958ms
      └─dbus.socket @958ms
        └─sysinit.target @958ms
          └─systemd-backlight@backlight:intel_backlight.service @1.759s +2ms
            └─system-systemd\x2dbacklight.slice @1.754s
              └─system.slice
                └─-.slice

My network wasn't up - so I couldn't check email until ~5s, but everything else was running.

(sidenote: the 4.5s kernel is an anomoly which will be fixed when 3.18 hits core)

Last edited by Trilby (2015-01-13 15:20:14)

kravecm · 2015-01-13 16:02:22

Yes, You're right in 3 things

I don't understand how targets work at all - and I'd like to understand them
I want my boot up to be more efficient for you to be able to start working
I want to fudge the numbers of systemd-analyze

However, this question/topic is mainly about thing number 1. I want to understand how systemd targets work to be able to organize my services and system startup.

Last edited by kravecm (2015-01-13 16:03:17)

Trilby · 2015-01-13 16:31:43

Systemd starts things in parallel. But targets are not considered complete until every requirement of that target reports that it is complete.

If you disable network manager, and just boot into your WM or DE not caring about an internet connection, then the reported time for multi-user target will undoubtedly be much faster. When you re-enable network manager and reboot, you'll still get to your WM or DE just as fast (ok maybe several ms slower), but multi-user target will not report as being complete until several seconds later.

Perhaps you could come up with a way to make network manager "lie" about when it is done. This would in fact be pretty easy. But it would remove absolutely nothing from your boot time. Your WM/DE doesn't wait for network manager to complete the connection* - they start in parallel. So while getting NM to "lie" about it's time would provide no benefit, but it could very well have undesirable side effects. If/when you have services that actually do require an internet connection, they might have an After=network.target or something similar (an email/imap syncing service would be one example). If you make NM lie about it's timing, then these other services could fail.

*note - they shouldn't. If they do, that's a problem that should be fixed. Mine certainly doesn't.

Last edited by Trilby (2015-01-13 16:33:00)

Alad · 2015-01-13 16:40:52

Proper solution to the "problem":

448ms connman.service
40ms connman-vpn.service

Don't know why you'd use NM in i3 anyway.

Last edited by Alad (2015-01-13 16:41:24)

Trilby · 2015-01-13 16:51:40

Alad, there's no way connman is actually getting a connection in 448 ms. So it is essentially going the route of lying about how long it takes.

Alad · 2015-01-13 17:18:01

I wouldn't believe it either, until I saw how quickly it connects from a down state. Admittedly it's a bit quirky, sometimes not connecting at all, or taking longer.

Last edited by Alad (2015-01-13 17:20:42)

Trilby · 2015-01-13 17:24:08

I wasn't suggesting disbelief as in awe, but rather disbelief due to it not being possible - at least not if you need a DHCP lease.

Awebb · 2015-01-13 18:23:50

I don't know, Trilby. The systemd-networkd DHCP is supposed to get a lease on the same host in 750 µs and the author reports, that "using networkd together with wpa_supplicant on [his] laptop on [his] crappy home wifi, the time from link-sense to fully configured network is roughly 50ms (most of that obviously spent on network latency due to the two round-trips a lease acquisition requires)".

I'll now try systemd-networkd.

My dhcpcd over ethernet takes around 8 seconds, because the network adapter does not seem to be ready for some reason when dhcpcd is run. Whatever stops it, has something do to with the way dhcpcd handles the device. If I disable dhcpcd and start it manually after the shell is loaded, it takes between 900ms and a second. Now, systemd-networkd seems to solve this in 200-220ms during the boot sequence or in 99-110ms, if invoked after all other targets are done.

I'd say you need to recalibrate your disbelief on awe again.

Last edited by Awebb (2015-01-13 18:27:58)

Trilby · 2015-01-13 18:29:25

Perhaps you are right - I'm only familiar with dhcpcd and dhclient, both of which would take far longer than that.

But just the same, this is all very tangential to the original question. NM is not blocking bootup while it's waiting for an IP address.

kravecm · 2015-01-13 18:41:35

I misunderstood targets. If I understand it correctly now, then target just marks which things it wants to be running, but not dependencies which determine when target should start launching its things. So target is more like group of services.

The service sets its dependencies:

 $ cat /usr/lib/systemd/system/slim.service 
[Unit]
Description=SLiM Simple Login Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/bin/slim -nodaemon
Restart=on-failure

[Install]
Alias=display-manager.service

And I also run wrong analysis to determine how long it takes to show SLIM, I should have run:

 $ systemd-analyze critical-chain slim.service
slim.service @5.603s
└─systemd-user-sessions.service @4.483s +1.106s
  └─basic.target @4.476s
    └─sockets.target @4.476s
      └─dbus.socket @4.476s
        └─sysinit.target @4.468s
          └─systemd-rfkill@rfkill0.service @5.602s +185ms
            └─system-systemd\x2drfkill.slice @5.602s
              └─system.slice @790ms
                └─-.slice @639ms

Last edited by kravecm (2015-01-13 18:41:59)

Arch Linux

#1 2015-01-13 14:40:43

How to enable systemd's service without waiting?

#2 2015-01-13 15:17:10

Re: How to enable systemd's service without waiting?

#3 2015-01-13 16:02:22

Re: How to enable systemd's service without waiting?

#4 2015-01-13 16:31:43

Re: How to enable systemd's service without waiting?

#5 2015-01-13 16:40:52

Re: How to enable systemd's service without waiting?

#6 2015-01-13 16:51:40

Re: How to enable systemd's service without waiting?

#7 2015-01-13 17:18:01

Re: How to enable systemd's service without waiting?

#8 2015-01-13 17:24:08

Re: How to enable systemd's service without waiting?

#9 2015-01-13 18:23:50

Re: How to enable systemd's service without waiting?

#10 2015-01-13 18:29:25

Re: How to enable systemd's service without waiting?

#11 2015-01-13 18:41:35

Re: How to enable systemd's service without waiting?

Board footer