Workaround: NetworkManager.service takes too long to start

NiteiaTt · 2013-06-18 17:40:26

My system has been booting really slow for quite a while now. I guessed it was a normal behavior, since I use KDE and it does tend to slow things a bit.
It wasn't until recently that I found out that, when booting, NetworkManager.service and polkit.service took around 10-15 seconds to be ready, which caused KDM to be delayed the same amount of time.
So, by playing around with things I stumbled upon a workaround, and I'd like to share it
I know what I did isn't precisely safe or, let's say, adequate, and there might be a safer and better solution to this problem, but this worked for me.
It should be noticed that I use KDE, and what I'm about to explain makes use of the "Pre-KDE Startup" Run On feature on System Settings/Startup and Shutdown/Autostart, hence making this explanation targeted to KDE-users
Although it may be adaptable to other DMs, I'm not sure

Here's what I did:
1. Disabled NetworkManager.service from system startup

 # systemctl disable NetworkManager.service

2. Created a script that starts, but not enables, NetworkManager.service, and place it somewhere consistent.
I put it in ~/Documents/Scripts/start_networkmanager.sh

#!/bin/bash
systemctl start NetworkManager.service &
exit 0

3. Created a simple program that acts as a wrapper, to be able to set root permissions on it:
I created it in ~/Documents/Scripts/start_networkmanager.c

 int main(void) {
  setuid(0);
  clearenv();
  system("/home/niteiatt/Documents/Scripts/start_networkmanager.sh"); /*Of course, one would put here the absolute path to the script*/
}

4. Compiled said program:

~ cd ~/Documents/Scripts/
~ gcc -o start_networkmanager start_networkmanager.c

5. Copied the program to /usr/bin

 # cp start_networkmanager /usr/bin/start_networkmanager

6. Set the suid bit (For the program to run as root withouth needing any password):

DISCLAIMER: As stated here: http://stackoverflow.com/questions/5561 … 198#556198 setting the suid bit to pretty much ANYTHING can be dangerous and can be exploited for security escalation. So be very careful when doing this.
Personally, I did it because when this script is running, I won't have any sort of internet connection, therefore making any sort of attack unlikely (I believe)
I AM taking a risk here

# chown root /usr/bin/start_networkmanager
# chmod ug+s /usr/bin/start_networkmanager

7. Back in ~/Documents/Scripts/, created other script, that's going to be used by KDE, I called it exec_start_networkmanager.sh

#!/bin/bash 
start_networkmanager &
exit 0

The purpose of making it run in the background is to make sure KDM doesn't stop waiting for NetworkManager, although to be honest, I don't know whether that would happen or not

8. Finally, in System Settings / Startup and Shutdown / Autostart, added our ~/Documents/Scripts/exec_networkmanager.sh and set it to "Pre-KDE Startup"

And that's it.
Output of systemd-analyze blame

 $ systemd-analyze time
Startup finished in 3.520s (kernel) + 10.801s (userspace) = 14.321s

$ systemd-analyze blame
          1.505s systemd-modules-load.service
          1.353s systemd-vconsole-setup.service
          1.332s dev-mqueue.mount
          1.286s dev-hugepages.mount
          1.285s sys-kernel-debug.mount
          1.263s tmp.mount
          1.241s run-media-music_partition.mount
          1.219s systemd-udev-trigger.service
          1.187s systemd-remount-fs.service
          1.165s run-media-shared_partition.mount
           901ms udisks2.service
           875ms dev-disk-by\x2duuid-c1493bb5\x2dd915\x2d4729\x2d85a2\x2db1a6ef2d8d3d.swap
           852ms systemd-sysctl.service
           649ms laptop-mode.service
           620ms systemd-udevd.service
           589ms systemd-tmpfiles-setup-dev.service
           477ms systemd-tmpfiles-setup.service
           291ms NetworkManager.service
           275ms systemd-readahead-replay.service
           257ms polkit.service
           207ms systemd-logind.service
           192ms temp-links-catalyst.service
           128ms systemd-readahead-collect.service
            69ms sys-kernel-config.mount
            37ms wpa_supplicant.service
            18ms ModemManager.service
            18ms lm_sensors.service
            15ms alsa-restore.service
            11ms upower.service
            10ms rtkit-daemon.service
             8ms cpupower.service
             5ms systemd-update-utmp.service
             4ms systemd-journal-flush.service
             3ms sys-fs-fuse-connections.mount
             3ms systemd-readahead-done.service
             1ms systemd-user-sessions.service
             1ms systemd-random-seed-load.service

That's what I did and it seems made the trick, I hope other people having the same problem as I can use this to workaround this weird situation until it's officially fixed

NoSavvy · 2013-06-18 18:24:32

I changed to "netctl" and using this setup shaved 10-12 seconds off boot time.
Only drawback is there is no tray icon.

NiteiaTt · 2013-06-18 18:27:08

I just can't find a way to make netctl work on my system. It just doesn't want to
Besides, I'm on a laptop, so I really need to stick to an automatic network management service

cookies · 2013-06-18 19:23:58

NoSavvy wrote:

I changed to "netctl" and using this setup shaved 10-12 seconds off boot time.
Only drawback is there is no tray icon.

Have you tried WiFiz?

NoSavvy · 2013-06-18 19:27:07

#cookies

No I haven't tried WiFiz but I will. Don't really need wifi though .

PReP · 2013-06-18 22:07:38

What about just: https://wiki.archlinux.org/index.php/Ne … ng_systemd

I for instance use "network.service:

[Unit]
Description=Network Connectivity
Wants=network.target
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network
ExecStart=/sbin/ip link set dev ${interface} mtu 1492 up
ExecStart=/sbin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev ${interface}
ExecStart=/sbin/ip route add default via ${gateway}
ExecStop=/sbin/ip addr flush dev ${interface}
ExecStop=/sbin/ip link set dev ${interface} down

[Install]
WantedBy=multi-user.target

Though this is with static IP in a stationary computer, i do not know what particular features you might need : )

Last edited by PReP (2013-06-18 22:08:13)

aposteeltje · 2014-05-16 11:47:20

If i set exec_networkmanager.sh to "Pre-KDE Startup"., i can't login anymore.
It keeps dropping me at the login screen.
Setting it to normal startup works just fine.

tumas · 2014-05-17 10:51:29

aposteeltje wrote:

If i set exec_networkmanager.sh to "Pre-KDE Startup"., i can't login anymore.
It keeps dropping me at the login screen.
Setting it to normal startup works just fine.

Since this is a quite old thread, i am not sure if this workaround is necessary at all. NetworkManager used to take the most time to load in the past, but on my system right now it loads within 248ms without any tweaks (KDM and KDE system).

Arch Linux

#1 2013-06-18 17:40:26

Workaround: NetworkManager.service takes too long to start

#2 2013-06-18 18:24:32

Re: Workaround: NetworkManager.service takes too long to start

#3 2013-06-18 18:27:08

Re: Workaround: NetworkManager.service takes too long to start

#4 2013-06-18 19:23:58

Re: Workaround: NetworkManager.service takes too long to start

#5 2013-06-18 19:27:07

Re: Workaround: NetworkManager.service takes too long to start

#6 2013-06-18 22:07:38

Re: Workaround: NetworkManager.service takes too long to start

#7 2014-05-16 11:47:20

Re: Workaround: NetworkManager.service takes too long to start

#8 2014-05-17 10:51:29

Re: Workaround: NetworkManager.service takes too long to start

Board footer