Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

On 2021-07-02, Zack Newman <zack@philomathiclife.com> wrote:
> When I start dhcpcd during booting the \xe2\x80\x9cnormal\xe2\x80\x9d
> way (i.e., rcctl enable dhcpcd), I am able to successfully dump the
> lease information associated with the alc0 interface (which is connected
> directly to my bridge modem); however when I start the command inside of
> /etc/hostname.alc0 during booting, I am unable to get lease information
> after. When the computer boots up, I successfully acquire a DHCPv6 lease
> as well as have a /60 routed to me. My IPv6 connectivity runs just fine
> too.

This is not a bug.

/etc/rc clears /var/run after starting the network (it can't do it earlier
because /var may be mounted over NFS). dhcpcd places its control socket
in /var/run/dhcpcd, so it is cleared as part of that.

You might get away with mv'ing the directory out of the way after starting
dhcpcd, and back again e.g. in rc.local, obviously it's a kludge.
Alternatively you'll need to either build your own copy of dhcpcd that
uses a different directory (set --rundir when you run configure), or
modify /etc/rc to skip that directory, e.g. by changing "rm -rf -- *"
to "rm -rf -- !(dhcpcd)". In both cases you will need to deal with
reinstating it after an OS update; if you use a custom dhcpcd then that
will need to be rebuilt from time to time; if you edited /etc/rc then
that will need to be reinstated after every update.

> I found a discussion on the blog
> (https://roy.marples.name/archives/dhcpcd-discuss/0003312.html
> <https://roy.marples.name/archives/dhcpcd-discuss/0003312.html>)
> belonging to the creator but now former maintainer, Roy
> Marples, of dhcpcd where a similar issue was had by someone
> running dhcpcd on their ARM32 server running a custom Linux
> 4.9 kernel. After much back-and-forth, it was discovered
> to be an issue with privsep not having the system calls
> fcntl64, fstat64, and TCGETS available. Those calls were added
> (https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-
> linux.c
> <https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-
> linux.c>) for Linux, and that fixed the issue. I realize that OpenBSD
> has pledge, so this may not be relevant at all and just a coincidence.

That is unrelated and is because Linux's closest equivalent to pledge
(SECCOMP) is too fine-grained to be usable without major pain in many
cases. So rather than saying "allow system calls that permit write
access to files" you must individually list the calls that currently
or might in the future be used for that - and they can vary depending
on machine architecture, also different libc's may use different calls
for the same basic operation, etc.