-1

I have this udhcpc service in my system:

[Unit]
Description=uDHCP Client Service
After=network.target
Conflicts=systemd-resolved.service

[Service]
Type=forking
ExecStart=/sbin/udhcpc -p /var/run/udhcpc.brg0.pid -i brg0 -R -b
ExecStop=/bin/sh -c 'test -f /var/run/udhcpc.brg0.pid && kill $(cat /var/run/udhcpc.brg0.pid)'

[Install]
WantedBy=multi-user.target

It's been working well, except systemd-analyze is showing that it is adding about 7 seconds to the boot time:

          7.388s udhcpc.service
          4.946s dev-mmcblk1p2.device
          1.303s uim-sysfs.service
           959ms dev-mmcblk1p4.device
           752ms dev-mmcblk1p3.device
           739ms dev-mmcblk1p1.device
           718ms systemd-hwdb-update.service
           .
           .

And here is the output of systemd-analyze critical-chain:

multi-user.target @15.164s
[[0;1;31mudhcpc.service @7.773s +7.388s[[0m
  network.target @7.551s
    [[0;1;31msystemd-networkd.service @6.724s +668ms[[0m
      [[0;1;31msystemd-udevd.service @1.854s +87ms[[0m
        [[0;1;31msystemd-tmpfiles-setup-dev.service @1.662s +70ms[[0m
          [[0;1;31msystemd-sysusers.service @1.353s +229ms[[0m
            [[0;1;31msystemd-remount-fs.service @1.044s +238ms[[0m
              systemd-journald.socket @911ms
                -.slice @281ms

I suppose the right way to fix this is to avoid using udhcpc and stick to the mechanism built into systemd, but unfortunately that's not my call. I'd like to at least optimize the boot time though. What are some things I can do?

Adam Lee
  • 2,983
  • 7
  • 35
  • 47

1 Answers1

1

The "problem" is systemd-networkd, which stops the boot until the network is configured -- and this is what you want to replace, not systemd-resolved.

Network autoconfiguration cannot be made any faster, because, when properly implemented, DHCP needs to check that the address isn't already in use, which involves sending a bunch of ARP packets and waiting for the timeout.

Since you insert your service between "network is configured" and "multi-user boot is complete" targets, you introduce a dependency where there was none before.

Network configuration is normally asynchronous, because any service that fails when the network is unconfigured at start would also fail when the network goes down later.

Simon Richter
  • 28,572
  • 1
  • 42
  • 64
  • At this point, I cannot replace `systemd-networkd`. And `udhcpc` is here to stay as well. I was merely asking if there is anything I can do to shorten the additional time the `udhcpc` service is taking during the boot. – Adam Lee Feb 18 '20 at 16:25
  • 1
    One problem is that `systemd-networkd` and `udhcpc` do the same thing, so you now have two conflicting services running. The other problem, which is what causes the long boot time, is that your service introduces a dependency that says that the system boot may not be considered complete until the network is fully configured (twice). Normal boot configures the network in the background, which is why that time doesn't count (i.e. it's not udhcpc being slow, but the change is that now the time is being counted where it wasn't before). – Simon Richter Feb 18 '20 at 16:39
  • 1
    (also note that `systemd-networkd` and `udhcpc` use different parameters -- the former sends a device ID, the latter doesn't, so from the DHCP server's point of view, these are two different clients that just happen to use the same MAC address -- so your device allocates two different addresses) – Simon Richter Feb 18 '20 at 16:53
  • Thanks. That probably explains why my device is getting 2 IP addresses. – Adam Lee Feb 18 '20 at 19:50