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 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 brd 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/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


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 dhcpcd@wlp2s0.service
         11.692s dhcpcd@wlp2s0.service
          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 user@120.service
           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 user@1000.service
            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 user-runtime-dir@120.service
            25ms sys-kernel-config.mount
            16ms user-runtime-dir@1000.service
            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 dhcpcd@eth0.service and dhcpcd@enp1s0f1 :

[siddharth@brightprogrammer ~]$ sudo systemctl status dhcpcd@eth0.service
● dhcpcd@eth0.service - dhcpcd on eth0
   Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; 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]: dhcpcd@eth0.service: Job dhcpcd@eth0.service/start failed with result 'dependency'.

[siddharth@brightprogrammer ~]$ sudo systemctl status dhcpcd@enp1s0f1.service
● dhcpcd@enp1s0f1.service - dhcpcd on enp1s0f1
   Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; 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

  • 1
    Look at systemctl status dhcpd@eth0 to see what it says. It's quite possible that it's "failed" and it's the one getting boot stuck for 90s... Also try systemd-analyze blame and systemd-analyze critical-chain which can be really helpful in troubleshooting boot time! Update your question with the answers. Use the {} button to format code as command output (markdown wants 4 space indent for that.) – filbranden Mar 5 at 5:22
  • @filbranden updated the question with the informations you needed. Thanks for editing the question! – Siddharth Mishra Mar 5 at 5:40
  • You missed blame in one of the analyze commands... Also include systemctl status dhcpcd@eth0 (sorry I had a typo last time) – filbranden Mar 5 at 5:43
  • @filbranden updated the question sir! – Siddharth Mishra Mar 5 at 6:08
  • Ah once again, that's systemctl status dhcpcd@eth0, with a "zero" and not an "O" (in your case, it looks like a lowercase "O".) – filbranden Mar 5 at 6:10

I'd say it's very likely the problem you're seeing is with the dhcpcd@eth0.service 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]: dhcpcd@eth0.service: Job dhcpcd@eth0.service/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 6 at 4:13

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.

  • I disabled netctl and dhcpcd and I am using NM only – Siddharth Mishra Mar 10 at 1:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.