A start job is running for eth0

Question

I am using a new installation of Arch Linux and whenever I boot my system I have to wait for 90 seconds as there is a start job running for my network interfaces.

I installed Arch yesterday and whenever I do ip a I get that ethernet interfaces is in DOWN state. I used a wired usb tether to complete the whole installation. I just want to remove that start job process while starting. I saw a solution somewhere in Arch community that I have to disable my interface using:

# systemctl disable dhcpcd@interface_name

I haven't done that yet. My question is if I disable that interface will that cause any problems in future? I am not using any LAN connections now. Will that cause any problems if in future I want to use a LAN or some kind of ethernet connection?

Output of uname -a:

[siddharth@brightprogrammer ~]$ uname -a
Linux brightprogrammer 4.19.26-1-lts #1 SMP Wed Feb 27 16:06:52 CET 2019 x86_64 GNU/Linux

Output of ip a:

[siddharth@brightprogrammer ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 80:fa:5b:5b:9e:47 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 94:b8:6d:c9:57:89 brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.201/24 brd 192.168.43.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 2153sec preferred_lft 2153sec
    inet6 2405:205:a061:4977:348c:2fe2:102:47ac/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::614a:460c:ff14:9caa/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Output of find /etc/systemd:

[siddharth@brightprogrammer ~]$ find /etc/systemd
/etc/systemd
/etc/systemd/journald.conf
/etc/systemd/coredump.conf
/etc/systemd/sleep.conf[siddharth@brightprogrammer ~]$ systemd-analyze

Startup finished in 5.369s (firmware) + 1.785s (loader) + 5.214s (kernel) + 1min 33.882s (userspace) = 1min 46.252s graphical.target reached after 1min 33.882s in userspace

/etc/systemd/journal-remote.conf
/etc/systemd/system.conf
/etc/systemd/timesyncd.conf
/etc/systemd/journal-upload.conf
/etc/systemd/networkd.conf
/etc/systemd/system
/etc/systemd/system/getty.target.wants
/etc/systemd/system/getty.target.wants/[email protected]
/etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service
/etc/systemd/system/bluetooth.target.wants
/etc/systemd/system/bluetooth.target.wants/bluetooth.service
/etc/systemd/system/multi-user.target.wants
/etc/systemd/system/multi-user.target.wants/NetworkManager.service
/etc/systemd/system/multi-user.target.wants/[email protected]
/etc/systemd/system/multi-user.target.wants/wicd.service
/etc/systemd/system/multi-user.target.wants/[email protected]
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/etc/systemd/system/network-online.target.wants
/etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
/etc/systemd/system/dbus-org.bluez.service
/etc/systemd/system/dbus-org.wicd.daemon.service
/etc/systemd/system/display-manager.service
/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service
/etc/systemd/logind.conf
/etc/systemd/user
/etc/systemd/user/sockets.target.wants
/etc/systemd/user/sockets.target.wants/p11-kit-server.socket
/etc/systemd/user/sockets.target.wants/pipewire.socket
/etc/systemd/user/sockets.target.wants/gpg-agent.socket
/etc/systemd/user/sockets.target.wants/dirmngr.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-extra.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-browser.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-ssh.socket
/etc/systemd/user/sockets.target.wants/pulseaudio.socket
/etc/systemd/user/default.target.wants
/etc/systemd/user/default.target.wants/xdg-user-dirs-update.service
/etc/systemd/user.conf
/etc/systemd/network
/etc/systemd/resolved.conf

Output of systemd-analyze :

[siddharth@brightprogrammer ~]$ systemd-analyze
Startup finished in 5.369s (firmware) + 1.785s (loader) + 5.214s (kernel) + 1min 33.882s (userspace) = 1min 46.252s
graphical.target reached after 1min 33.882s in userspace

Output of systemd-analyze critical-analyze :

[siddharth@brightprogrammer ~]$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.

graphical.target @1min 33.882s
└─gdm.service @1min 33.615s +265ms
  └─systemd-user-sessions.service @1min 33.503s +110ms
    └─network.target @1min 33.501s
      └─wpa_supplicant.service @15.761s +638ms
        └─basic.target @11.036s
          └─sockets.target @11.036s
            └─dbus.socket @11.036s
              └─sysinit.target @11.028s
                └─systemd-backlight@backlight:intel_backlight.service @14.008s >
                  └─system-systemd\x2dbacklight.slice @14.006s
                    └─system.slice @2.915s
                      └─-.slice @2.915s

Output of systemd-analyze blame :

[siddharth@brightprogrammer ~]$ systemd-analyze blame
         11.692s [email protected]
         11.692s [email protected]
          6.472s lvm2-monitor.service
          4.616s wicd.service
          3.222s systemd-journal-flush.service
          3.188s NetworkManager.service
          2.719s bluetooth.service
          2.711s systemd-logind.service
          1.395s systemd-sysusers.service
          1.216s systemd-udevd.service
          1.213s ldconfig.service
           981ms udisks2.service
           971ms polkit.service
           649ms [email protected]
           638ms wpa_supplicant.service
           600ms systemd-modules-load.service
           526ms systemd-tmpfiles-setup.service
           501ms systemd-tmpfiles-setup-dev.service
           493ms upower.service
           487ms systemd-udev-trigger.service
           464ms systemd-journald.service
           371ms systemd-journal-catalog-update.service
           338ms systemd-sysctl.service
           268ms colord.service
           265ms gdm.service
           260ms kmod-static-nodes.service
           238ms dev-sda2.swap
           236ms accounts-daemon.service
           142ms systemd-random-seed.service
           135ms systemd-backlight@backlight:intel_backlight.service
           110ms systemd-user-sessions.service
            91ms [email protected]
            81ms systemd-update-utmp.service
            54ms systemd-remount-fs.service
            48ms sys-kernel-debug.mount
            35ms systemd-tmpfiles-clean.service
            28ms dev-hugepages.mount
            26ms [email protected]
            25ms sys-kernel-config.mount
            16ms [email protected]
            15ms dev-mqueue.mount
             9ms rtkit-daemon.service
             6ms systemd-update-done.service
             4ms systemd-rfkill.service
             3ms sys-fs-fuse-connections.mount
             2ms tmp.mount

Output of systemctl status [email protected] and dhcpcd@enp1s0f1 :

[siddharth@brightprogrammer ~]$ sudo systemctl status [email protected]
● [email protected] - dhcpcd on eth0
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor pre>
   Active: inactive (dead)

Mar 05 09:42:42 brightprogrammer systemd[1]: Dependency failed for dhcpcd on eth0.
Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Job [email protected]/start failed with result 'dependency'.

[siddharth@brightprogrammer ~]$ sudo systemctl status [email protected]
● [email protected] - dhcpcd on enp1s0f1
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; vendor pr>
   Active: inactive (dead)

I recently disabled enp1s0f1. That might be the reason it is disabled.

I can also provide the output of journalctl -xe but that is very large! Also I suspect that dhcpcd is somehow confused between eth0 and my enp1s0f1

Welcome , also you need to remove Wicd because you have NetworkManager already installed. — GAD3R, Mar 05 '19 at 20:25

score 3 · Accepted Answer · answered Mar 05 '19 at 13:43

I'd say it's very likely the problem you're seeing is with the [email protected] that's configured on your system. So my recommendation would be to disable it, hopefully that's enough to make that timeout during boot disappear:

$ sudo systemctl disable dhcpcd@eth0

I'll go over the evidence to support that claim. There's more troubleshooting that can be done here, I'll suggest some more steps (in case you want to look further, or troubleshoot similar issues in the future.)

The main evidence of the issue is the message on output of systemctl status dhcpcd@eth0 which says:

Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Job [email protected]/start failed with result 'dependency'.

Failed with result "dependency" means, in this case, it was waiting for something else, that failed. This service will have a dependency on eth0.device and this device will not appear, so that's the probable source of the timeout. You can take a look at systemctl status eth0.device to see if anything else shows up, it's possible it will (but then, it's possible it won't.)

Like you mentioned in your question, there's probably a mix up between eth0 and the actual device name of enp1s0f1 in your system. systemd (more specifically udevd) will rename network interfaces to give them a consistent name and this typically happens very early at boot (sometimes even before systemd comes up), so systemd will not really see the eth0 name anymore.

If you want to enable DHCP on that interface in the future, enable dhcpcd@enp1s0f1 instead.

The output of systemd-analyze critical-chain supports the hypothesis of timeout on that dhcpcd@eth0 service, which you can see from these two steps:

└─network.target @1min 33.501s    
  └─wpa_supplicant.service @15.761s +638ms

The times after @ are the clock times right after boot. The wpa_supplicant service came up 13s after systemd started, but network.target was only reached at 1m33s (roughly the 90s you talk about.)

You would probably had seen dhcpcd@eth0 here more explicitly, but the unit actually went into the "loaded"/"inactive" state, rather than "failed", so that's probably why it isn't listed prominently here (and in systemd-analyze blame), which would have helped point it out as the culprit.

Finally, one step that's usually a great start when troubleshooting systemd boot issues is to start by looking at the bare systemctl status output, which will tell you whether the system is in "degraded" state, which indicates that something failed during boot. You want to ensure the system status will be "running", so investigating those failures will typically uncover issues such as timeouts, etc.

You can proceed the investigation from that point by looking at output of systemctl, which will list all active units and their status, if you see problems there, look further by investigating specific units (with systemctl status <unit> or journalctl -u <unit>.) Command systemctl --state=failed is also useful to show only the failed units.

Finally, checking the journal is really good to make correlations. Command journalctl -b shows the journal since the system booted, so it's great to look into issues during boot. As mentioned before, journalctl -u <unit> is useful to investigate logs for a single unit.

Hopefully these tips will be helpful to you in digging deeper and understanding what is happening in your system. Also hoping that disabling that dhcpcd@eth0 is enough to solve the boot delay you're experiencing.

when I do `systemctl status eth0.device`, It says : `Loaded : loaded` and `Active : inactive (dead)` — Siddharth Mishra, Mar 06 '19 at 04:13

score 0 · Answer 2 · edited Apr 05 '19 at 22:43

0

I finally resolved this issue, by re-enabling the systemd unit for the profile specified (eth0).

netctl reenable eth0

Now the 90 second bootup is cleared after a reboot.

edited Apr 05 '19 at 22:43

Rui F Ribeiro

55,929
26
146
227

answered Mar 09 '19 at 18:21

cifranix

1
2

I disabled netctl and dhcpcd and I am using NM only – Siddharth Mishra Mar 10 '19 at 01:07

Grzegorz Olbryś · Answer 3 · 2019-12-17T01:01:13.477

The problem is when you don't have configured network yet (typical after fresh installation) but system trying to start whole network stuff. Untill the net config will be properly established just disable the dependency of systemd user sessions and the network daemons.

From: /usr/lib/systemd/system/systemd-user-sessions.service

Section: [Unit]

Line: After=....

remove network.target then execute systemctl daemon-reload

A start job is running for eth0

3 Answers3