[SOLVED] dhcpcd slows down boot and does not seem to be required

ondoho · 2019-03-06 07:23:46

Hello all,
my desktop machine is connected to a router via cable.
systemd-networkd connects it to a static IP: /etc/systemd/network/20-wired.network:

[Match]
Name=eth0
[Network]
Address=192.168.0.10/24
Gateway=192.168.0.1

(and yes, i'm using the old interface names)

systemd-resolved takes care of name reolution. /etc/systemd/resolved.conf is all commented out because systemd-resolved will use /etc/resolv.conf as a provider if it's not a symlink.

For a long time I have been using opennic as my DNS provider.
Opennic recommends to regularly rebuild the list of nameservers to use. I have a script that gets them from here and rewrites /etc/resolv.conf accordingly.
The script is started at boot time by a systemd service:

[Unit]
Description=opennic DNS configuration
Requires=network.target
Wants=network-online.target
After=network-online.target

[Service]Type=simple
ExecStart=/home/ondoho/.config/scripts/opennic
ProtectSystem=yes
ReadWriteDirectories=/etc
Restart=on-failure
RestartSec=5min

[Install]
WantedBy=multi-user.target

However, it seems that dhcpcd is getting in the way.
I did some research, and it seems like dhcpcd is not actually required.
the only related service I could find is dhcpcd@eth0.service. I disabled it, but after a reboot it is there again, and dhcpcd is running.
I can't find out what's starting it. Is there a command for that?
Every 'systemd-analyze blame' shows that dhcpcd@eth0.service wastes many seconds each boot.
I cannot find out what it is actually doing on my system, since

i use a static address
i have my own nameserver solution

Does dhcpcd fulfil some other crucial task I'm not aware of?

I edited /etc/dhcpcd.conf according to this and it now looks like this:

nohook resolv.conf
noarp
interface eth0
static ip_address=192.168.0.10/24
static routers=192.168.0.1

another reboot, and 'systemd-analyze blame' shows the same delay for dhcpcd@eth0.service again.

For now I've masked dhcpcd@eth0.service and everything works fine. No more delays, internet works. I can post here, watch youtube videos and ssh into my server.
Why do I even need it?
What is starting it?
Can I uninstall it?
Is masking a clean solution?
_____________________

I read on the forums that "all packages of the base group are expected to be installed on every arch system anyhow", but I read this, too, and it also mentions non-essential software.
Which is correct?

Last edited by ondoho (2019-03-13 04:15:37)

ayekat · 2019-03-06 12:51:55

If dhcpcd@eth0.service is not enabled, it should not start all by its own. Verify that it is indeed disabled (check the tree under /etc/systemd/system to be sure).

It is possible that some other service starts it; is there anything in the journal right before that dhcpcd@eth0.service starts?

Masking is more of a workaround IMHO, so certainly not a long-term solution, but it may be worth trying to mask it to see if any other component then reports an error.
In the same vein would be to test what happens if you uninstall dhcpcd (temporarily).

ondoho · 2019-03-07 06:02:57

I have now unmasked dhcpcd@eth0.service again for troubleshooting, and rebooted.

ayekat wrote:

If dhcpcd@eth0.service is not enabled, it should not start all by its own. Verify that it is indeed disabled (check the tree under /etc/systemd/system to be sure).

$> systemctl is-enabled dhcpcd@eth0.service
disabled
$> find /etc/systemd/system -name '*dhcpcd*'
$>

It is possible that some other service starts it; is there anything in the journal right before that dhcpcd@eth0.service starts?

not right before, but the first mention of dhcpcd says that there's a "system-dhcpcd.slice".
I already looked that up yesterday but could not find anything beyond the short man page for 'systemd.slice' and some very basic unit files under /lib/systemd - definitely no information why it would insist on starting dhcpcd.
anyhow, curated output:

journalctl -b |grep -i dhcp
Mar 07 07:04:20 arch systemd[1]: Created slice system-dhcpcd.slice.
Mar 07 07:04:21 arch systemd[1]: Starting dhcpcd on eth0...
Mar 07 07:04:21 arch dhcpcd[505]: eth0: waiting for carrier
Mar 07 07:04:23 arch dhcpcd[505]: eth0: carrier acquired
Mar 07 07:04:24 arch dhcpcd[505]: DUID 00:04:00:00:00:00:00:00:00:00:00:00:d8:cb:8a:c1:b3:ae
Mar 07 07:04:24 arch dhcpcd[505]: eth0: IAID 8a:c1:b3:ae
Mar 07 07:04:24 arch dhcpcd[505]: eth0: adding address fe80::dacb:8aff:fec1:b3ae
Mar 07 07:04:24 arch dhcpcd[505]: eth0: using static address 192.168.0.10/24
Mar 07 07:04:24 arch dhcpcd[505]: eth0: adding route to 192.168.0.0/24
Mar 07 07:04:24 arch dhcpcd[505]: eth0: adding default route via 192.168.0.1
Mar 07 07:04:24 arch dhcpcd[505]: forked to background, child pid 562
Mar 07 07:04:24 arch systemd[1]: Started dhcpcd on eth0.
Mar 07 07:04:24 arch audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dhcpcd@eth0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 07:04:24 arch kernel: audit: type=1130 audit(1551935064.059:54): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dhcpcd@eth0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 07:04:24 arch dhcpcd[562]: eth0: soliciting an IPv6 router
Mar 07 07:04:25 arch dhcpcd[562]: eth0: Router Advertisement from fe80::125f:49ff:fe6a:3341
Mar 07 07:04:25 arch dhcpcd[562]: eth0: adding address 2001:14ba:9ff:3200:dacb:8aff:fec1:b3ae/64
Mar 07 07:04:25 arch systemd-networkd[276]: eth0: Could not acquire DHCPv6 lease on NDisc request: Address already in use
Mar 07 07:04:25 arch dhcpcd[562]: eth0: adding route to 2001:14ba:9ff:3200::/64
Mar 07 07:04:25 arch dhcpcd[562]: eth0: adding default route via fe80::125f:49ff:fe6a:3341
Mar 07 07:04:25 arch dhcpcd[562]: eth0: soliciting a DHCPv6 lease
Mar 07 07:04:39 arch systemd-networkd[276]: eth0: Could not acquire DHCPv6 lease on NDisc request: Address already in use
Mar 07 07:04:56 arch systemd-networkd[276]: eth0: Could not acquire DHCPv6 lease on NDisc request: Address already in use
...

The last line keeps repeating every 15s or so. Maybe it means there's some sort of conflict between dhcpcd and systemd-networkd.

-- Full output --

btw, when i reboot with dhcpcd@eth0 masked, there's no output at all for 'journalctl -b | grep -i dhcp'.

it may be worth trying to mask it to see if any other component then reports an error.

system ran with this service masked the rest of the evening yesterday - i have noticed no errors.

some more interesting info:

$> systemd-analyze blame
          2.476s dhcpcd@eth0.service
          1.166s systemd-logind.service
           813ms smartd.service
           742ms home-server.mount
           629ms systemd-resolved.service
           494ms dev-sda2.device
           488ms systemd-timesyncd.service
           466ms ufw.service
           311ms home-ondoho-html.mount
           154ms systemd-journal-flush.service
           150ms systemd-networkd.service
           148ms systemd-modules-load.service
           146ms systemd-udevd.service
           133ms systemd-fsck@dev-disk-by\x2duuid-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.service
           107ms user@1000.service
            99ms systemd-fsck@dev-disk-by\x2duuid-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.service
            90ms lm_sensors.service
            82ms systemd-udev-trigger.service
            78ms systemd-tmpfiles-clean.service
            76ms home-data2.mount
            71ms home-data.mount
            64ms systemd-sysctl.service
            56ms haveged.service
            53ms rpc-statd.service
            52ms systemd-tmpfiles-setup-dev.service
            49ms systemd-journald.service
            40ms alsa-restore.service
            38ms systemd-user-sessions.service
            35ms systemd-tmpfiles-setup.service
            34ms hdparm_wd_my_passport.service
            30ms dev-hugepages.mount
            27ms dev-disk-by\x2duuid-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.swap
            27ms dev-mqueue.mount
            26ms sys-kernel-config.mount
            24ms systemd-binfmt.service
            21ms systemd-update-utmp.service
            20ms systemd-random-seed.service
            15ms rpcbind.service
            13ms sys-kernel-debug.mount
            10ms systemd-remount-fs.service
             9ms kmod-static-nodes.service
             7ms user-runtime-dir@1000.service
             3ms tmp.mount
             3ms proc-sys-fs-binfmt_misc.mount

$> systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

multi-user.target @4.291s
└─opennic.service @4.289s
  └─network-online.target @4.287s
    └─network.target @4.286s
      └─dhcpcd@eth0.service @1.808s +2.476s
        └─basic.target @1.806s
          └─sockets.target @1.805s
            └─dbus.socket @1.803s
              └─sysinit.target @1.791s
                └─systemd-timesyncd.service @1.300s +488ms
                  └─systemd-tmpfiles-setup.service @1.246s +35ms
                    └─local-fs.target @1.241s
                      └─home-data.mount @1.165s +71ms
                        └─systemd-fsck@dev-disk-by\x2duuid-nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn.service @1.020s +133ms
                          └─dev-disk-by\x2duuid-nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn.device @994ms

the critical-chain suggests i should look into how exactly network.target is built.
I looked that up but could not find anything beyond the short man page for 'systemd.target' and some very basic unit files under /lib/systemd - definitely no information why it would insist on starting dhcpcd.

Last edited by ondoho (2019-03-07 06:06:04)

Head_on_a_Stick · 2019-03-07 08:22:34

ondoho wrote:

i should look into how exactly network.target is built

systemctl cat network.target

Run

systemd-analyze unit-paths
systemd-analyze --user unit-paths

To show all the directories from which unit files are run, `ls -lR` on those directories may be illuminating.

See also https://www.freedesktop.org/software/sy … oad%20Path

EDIT: I think the live ISO has a udev rule to run dhcpcd automatically for ethernet interfaces, any chance that could be the case for your system?

Last edited by Head_on_a_Stick (2019-03-07 08:26:55)

rsmarples · 2019-03-07 12:47:30

systemd-networkd[276]: eth0: Could not acquire DHCPv6 lease on NDisc request: Address already in use

Exactly correct - you cannot have two DHCPv6 clients in the happy flow.

ondoho · 2019-03-10 14:43:30

OK, I will trust the archwiki when it says that dhcpcd is "not essential", and simply uninstall it.
Will report back.

HoaS: given our history I'd prefer to minimize any contact to you. I hope you can restrain yourself whenever you see the ondoho handle in the future.

Head_on_a_Stick · 2019-03-10 15:02:08

ondoho wrote:

given our history I'd prefer to minimize any contact to you.

https://wiki.archlinux.org/index.php/Co … ther_users

I would appreciate an answer to my queries, uninstalling the dhcpcd package could be considered a workaround and I am interested to know the root cause of your problem (and perhaps others may feel the same).

ondoho wrote:

I hope you can restrain yourself whenever you see the ondoho handle in the future.

No, I will continue to offer constructive comments in any thread in which I feel that I can make a positive contribution.

The identity of the OP is entirely irrelevant to me.

ondoho · 2019-03-13 04:14:50

So I uninstalled

dhcpcd - systemd-resolved takes care of DNS now.
netctl - when I made this install I probably still had some wifi, also systemd wasn't as advanced as it is now. haven't needed or used netctl for a long while
openresolv - since i manage DNS via opennic it seems superfluous

No ill effects, and bootup is that much faster now:

$> systemd-analyze blame
          1.157s systemd-logind.service
           967ms home-server.mount
           861ms smartd.service
           653ms systemd-resolved.service
           576ms systemd-timesyncd.service
           512ms dev-sda2.device
           406ms ufw.service
           364ms logrotate.service
           173ms systemd-networkd.service
           159ms systemd-modules-load.service
           134ms systemd-fsck@dev-disk-by\x2duuid-0b92040d\x2d7c29\x2d4785\x2db3e2\x2dd5c32dc23bb1.service
           133ms systemd-fsck@dev-disk-by\x2duuid-ec66d628\x2d45db\x2d4afc\x2d8b54\x2dff91671cd929.service
           102ms systemd-journal-flush.service
           102ms home-data2.mount
            89ms systemd-udevd.service
            81ms systemd-tmpfiles-setup.service
            79ms systemd-udev-trigger.service
            79ms lm_sensors.service
            76ms systemd-tmpfiles-setup-dev.service
            75ms hdparm_wd_my_passport.service
            74ms systemd-user-sessions.service
            74ms user@1000.service
            73ms alsa-restore.service
            66ms rpc-statd.service
            53ms haveged.service
            43ms home-data.mount
            42ms systemd-journald.service
            41ms systemd-binfmt.service
            33ms systemd-update-utmp.service
            26ms rpcbind.service
            20ms systemd-sysctl.service
            19ms proc-sys-fs-binfmt_misc.mount
            19ms systemd-random-seed.service
            19ms kmod-static-nodes.service
            16ms dev-disk-by\x2duuid-0d5d4f67\x2ddc58\x2d448e\x2d9363\x2d263b703f9723.swap
            12ms systemd-remount-fs.service
            10ms dev-hugepages.mount
             9ms user-runtime-dir@1000.service
             6ms dev-mqueue.mount
             4ms sys-kernel-debug.mount
             3ms sys-kernel-config.mount
             3ms tmp.mount

I had also tried the commands from post #4, and searched all possible directories for more clues as to what starts dhcpcd@eth0, but found none.
I did the same again now and of course didn't find anything either.

The only clue ever was this line from journalctl: "systemd[1]: Created slice system-dhcpcd.slice."
Have to read up on systemd slices I guess...

Anyhow, thanks for helping out.
Mystery solved without gaining much insight.

Lone_Wolf · 2019-03-13 09:44:06

dhcpcd - systemd-resolved takes care of DNS now.

that's incomplete , it should be something like :
I replaced dhcpcd functionality with the systemd-networkd & systemd-resolved combo.

Other then that i agree.

Basically you need to choose which network tool you use and disable all others.

Arch Linux

#1 2019-03-06 07:23:46

[SOLVED] dhcpcd slows down boot and does not seem to be required

#2 2019-03-06 12:51:55

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#3 2019-03-07 06:02:57

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#4 2019-03-07 08:22:34

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#5 2019-03-07 12:47:30

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#6 2019-03-10 14:43:30

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#7 2019-03-10 15:02:08

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#8 2019-03-13 04:14:50

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

#9 2019-03-13 09:44:06

Re: [SOLVED] dhcpcd slows down boot and does not seem to be required

Board footer