Hi. On Sun, Jul 07, 2019 at 09:58:46AM +0300, andreimpope...@gmail.com wrote: > On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote: > > > > If you read the full thread, you will find where I found and fixed that > > problem, by killing dhcpd5 with htop, and restarting networking, and > > the problem was fixed, everything then worked correctly, > > Did you ever find out why dhcpcd5 was even starting?
I solved this mystery. Took an upgrade to buster, and somewhat botched network configuration in the result. But it was worth it. First, unlike ISC dhclient, which is the 'goto' DHCP client in Debian, Raspbian promoted dhcpcd5 into this role. Second, unlike dhclient, dhcpcd5 can work as a systemwide daemon, and if run like that it tries to get a lease on every network interface if it's UP and it's not a "lo". This can be changed via dhcpcd.conf, but it's not done by default. Third, /etc/init.d/dhcpcd contains a useful safeguard - a single interface defined as "inet dhcp" in e/n/i prevents systemwide daemon from running. In full accordance with Debian policy, dhcpcd5 tries to run such daemon by default. So far - so good, but buster's dhcpcd added fourth - a systemd unit that runs /usr/sbin/dhcpcd regardless of a safeguard. A result, assuming systemd as PID 1 - stretch's dhcpcd respects e/n/i, buster's - does not. As an added "bonus" - buster's dhcpcd does not respect "metric" setting in these circumstances. A fun parts here are: 1) Problem is easily solved with the usual "systemctl disable/systemctl stop" combo. 2) Debian does not exibit this behaviour by default, user has to install dhcpcd5 package (which I do, because $REASONS). 3) Raspbian seem to be broken by default in this regard, but … you're not supposed to edit e/n/i if using Raspbian as far as I understand. Because you can always get DHCP lease and it's confusing to the user and all that :) As an upside, they finally fixed dhcpcd's ntp hook - it was broken in stretch. Reco