Making DHCPCD stay alive with no carrier

throbscottle · 2020-11-07 12:17:00

Occasionally I boot up the laptop before I remember to make my phone be a hotspot. By then DHCPCD has bombed out and I have to start it manually. I created a drop-in file
/etc/systemd/system/dhcpcd\@wlp3s0.d/dhcpcdrestart.conf containing
[Service]
Restart=always
and I thought this would be all it needs, but apparently not so.

Also have one in there called no-wait.conf containing
[Service]
ExecStart=
ExecStart=/usr/bin/dhcpcd -b -q %I
which are the defaults DHCPCD was installed with.
my dhcpcd.conf (comments removed) is mostly defaults and looks like:

controlgroup wheel
hostname
duid
persistent
vendorclassid
option domain_name_servers, domain_name, domain_search
option classless_static_routes
option interface_mtu
option rapid_commit
require dhcp_server_identifier
noarp
ipv4only

I'm not sure if it's actually being loaded though because I'm a member of the wheel group but still have to sudo the manual start.

I can't find any way to show what options it's actually using - systemctl status only shows it using -q and -w, so not even a mention of the -b and -q it's supposed to have!

Can anyone suggest what is going on?
Big thanks in advance!

seth · 2020-11-07 14:51:31

man dhcpcd wrote:

-t, --timeout seconds
Timeout after seconds, instead of the default 30. A setting of 0 seconds causes
dhcpcd to wait forever to get a lease. If dhcpcd is working on a single interface
then dhcpcd will exit when a timeout occurs, otherwise dhcpcd will fork into the
background.

throbscottle · 2020-11-07 21:12:39

I looked at that one. But in the case that no DHCP server is present, won't it make the boot process pause indefinitely?

seth · 2020-11-07 21:19:49

You could try whether "-t 300" w/o carrier delays your boot by 5 minutes, but the dhcpcd call in the service forks immediately (-b) anyway, so I don't see why a longer/infinite timeout would have an impact here.

rsmarples · 2020-11-08 02:49:12

Starting dhcpcd for an interface which isn't ready or may not have a DHCP server will bomb out by default.

You can start dhcpcd for all interfaces (but limit in dhcpcd.conf).
You could add the -b flag to force immediate background on a per interface setup.

I can't find any way to show what options it's actually using - systemctl status only shows it using -q and -w, so not even a mention of the -b and -q it's supposed to have!

This I suspect is the issue. dhcpcd is starting here in master mode with the -w flag.
That effectively makes your per interface setup useless.

I don't know enough about systemd to help more, sorry.

seth · 2020-11-08 07:10:00

Output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

/etc/systemd/system/dhcpcd\@wlp3s0.d/dhcpcdrestart.conf

Somehow spurious escape code.
Since I'm not sure what path you actually created, try to

systemctl edit dhcpcd@wlp3s0.d

and use that path.

throbscottle · 2020-11-09 12:36:23

Yay, sorted it! Thanks very much for the help, everybody.
I did:
sudo rm -rf /etc/systemd/system/dhcpcd\@wlp3s0.d/
sudo systemctl edit dhcpcd@wlp3s0
and added
[Service]
Restart=always
to the override file. (which is all I thought it needed in the first place)
To test I did
sudo systemctl stop dhcpcd@wlp3s0
turned off wireless at the switch, then
sudo systemctl start dhcpcd@wlp3s0
and checked
systemctl list-units
which showed dhcpcd@wlp3s0 to be in a constant state of activating. Turned the wireless back on and it went straight to active/running.

So, the Arch Wiki needs updating wrt these dropin files, because the instructions plainly didn't work. (Not volunteering, someone way more knowledgeable than me needs to do that!)

Very grateful for help received, this has been bugging me for a long, long time!

seth · 2020-11-09 12:58:45

ls /etc/systemd/system/

throbscottle · 2020-11-09 23:31:43

Is useful?

ls -1 /etc/systemd/system/
dhcpcd@wlp3s0.service
dhcpcd@wlp3s0.service.d
display-manager.service
getty.target.wants
multi-user.target.wants
nordvpnd.service
nordvpnd.service.d
printer.target.wants
sockets.target.wants

ls -1 /etc/systemd/system/dhcpcd\@wlp3s0.service.d/
override.conf

seth · 2020-11-10 06:45:00

It was to show you that the path is NOT escaped and because you said

I created a drop-in file /etc/systemd/system/dhcpcd\@wlp3s0.d/dhcpcdrestart.conf

That literal path ("mkdir /etc/systemd/system/dhcpcd\\@wlp3s0.d") is wrong.

You can, but don't have to escape "@" in your shell (depends a bit on your shell, but "@" is no special char, try "touch /tmp/@"), but the escape code has no business being in the actual path.

throbscottle · 2020-11-10 16:17:26

I just pasted it from Konsole. Hmmmm, let's see... Auto-complete is the culprit - it just puts the slash in there. I didn't think to take it out. But thanks for pointing that out to me!

Arch Linux

#1 2020-11-07 12:17:00

Making DHCPCD stay alive with no carrier

#2 2020-11-07 14:51:31

Re: Making DHCPCD stay alive with no carrier

#3 2020-11-07 21:12:39

Re: Making DHCPCD stay alive with no carrier

#4 2020-11-07 21:19:49

Re: Making DHCPCD stay alive with no carrier

#5 2020-11-08 02:49:12

Re: Making DHCPCD stay alive with no carrier

#6 2020-11-08 07:10:00

Re: Making DHCPCD stay alive with no carrier

#7 2020-11-09 12:36:23

Re: Making DHCPCD stay alive with no carrier

#8 2020-11-09 12:58:45

Re: Making DHCPCD stay alive with no carrier

#9 2020-11-09 23:31:43

Re: Making DHCPCD stay alive with no carrier

#10 2020-11-10 06:45:00

Re: Making DHCPCD stay alive with no carrier

#11 2020-11-10 16:17:26

Re: Making DHCPCD stay alive with no carrier

Board footer