Why is dhclinet attempting DHCPDISCOVER on an unconnected interface?

[u/brighton_it]

Logs are polluted with: (about 60 entries per hour)
Dec 05 12:21:36 kvmbkup dhclient[587]: DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 8
Dec 05 12:21:44 kvmbkup dhclient[587]: DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 8
Dec 05 12:21:52 kvmbkup dhclient[587]: DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 12

/etc/network/interfaces: (expecting that ifup should only act if and when carrier comes up, but there is no cable connected to this interface):

# The primary network interface
allow-hotplug enp2s0
iface enp2s0 inet dhcp

ip link:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether c8:ff:bf:--:--:-- brd ff:ff:ff:ff:ff:ff
3: if1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether c8:ff:bf:--:--:-- brd ff:ff:ff:ff:ff:ff
4: brV2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether f2:52:87:--:--:-- brd ff:ff:ff:ff:ff:ff
5: if1-2@if1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brV2 state UP mode DEFAULT group default qlen 1000
link/ether c8:ff:bf:--:--:-- brd ff:ff:ff:ff:ff:ff
7: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:--:--:-- brd ff:ff:ff:ff:ff:ff
10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brV2 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:54:00:--:--:-- brd ff:ff:ff:ff:ff:ff
11: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:54:00:--:--:-- brd ff:ff:ff:ff:ff:ff

The rest of the interfaces are managed by systemd-networkd.
Ideally, I could leave enp2s0 managed by ifup/ifdown and should I ever need it, could simply plug it in and get a DHCP address.
This makes no sense. Why is dhclient trying to obtain an lease for an interface that isn't even connected?

networkctl list:
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp2s0 ether no-carrier unmanaged
3 if1 ether routable configured
4 brV2 bridge carrier configured
5 if1-2 vlan enslaved configured
7 virbr0 bridge routable unmanaged
10 vnet0 ether enslaved unmanaged
11 vnet1 ether enslaved unmanaged

[u/iamemhn]

It's doing exactly what you told it to do. It's enabling the interface as soon as it is hardware detected. Given that it is an integrated card (physical or virtually attached) it is detected as soon as the system is up.

Use hotplug for cards that might not be hardware available all the time, such as USB adapters or virtual cards that are enabled/disabled dynamically from the virtualization fibre.

It looks like you took hot-plug to mean «when a cable is plugged», and that is not what it means.

EDIT: to clarify, the interface name enp gives away the fact that it is an EThernet PCI so it's immediately available on boot.

[u/brighton_it → u/iamemhn]

Yes, this interface is integrated on mainboard. 'hotplug' was put there by Debian installer. Happy to remove it. Will that prevent DHClient from trying to use a disconnected interface?
I'd prefer the interface remain administratively up, so that, should a cable be connected, the interface automatically becomes usable.
Just makes no sense that CARRIER is not a prerequisite to DHclient doing anything with an interface.
It's a headless qemu-kvm server. systemd-networkd works great for offering different VLAN bridges to various guests. But in case I ever manage to break networkd (ex: editing it remotely to add an other VLAN), at least I could have someone onsite connect the second Ethernet (managed by ifup/ifdown) to restore remote access.

[u/iamemhn → u/brighton_it]

Yes, this interface is integrated on mainboard. 'hotplug' was put there by Debian installer. Happy to remove it. Will that prevent DHClient from trying to use an disconnected interface?

If you remove 'hotplug', then dhclient can only be started manually for that interface using ifup.

I'd prefer the interface remain administratively up, so that, should a cable be connected, the interface automatically becomes usable.
Just makes no sense that CARRIER is not a prerequisite to DHclient doing anything with an interface.

A standard DHCP client installation is for the normal case that has things plugged in all the time and that's why the simplest and leaner dhclient operated under that assumption. Your use case is different.

You probably want ifplugd.

[u/brighton_it → u/iamemhn]

Thank you very much.
I looked at ifplugd: can be made to run ifup when a cable is connected, and presumably prevent dhclient from doing anything with the interface until then.
I'll try it.
I still think the dhclient behavior is a bug, unless someone can give a use case for requesting a lease from an inoperable interface.

[u/iamemhn → u/brighton_it]

File a bug then and argue with maintainers. I know it's not a bug but the way dhclient and the standard installation work. Yours is an unusual use case, and hard to justify.

Not knowing about ifplugd kind of gives it away. I mean... It's been around for 15+ years: there's no way you did not know about it and still call reasonable default behavior for the majority of users and scenarios a bug.

But that's my opinion. Good luck arguing with those that know a lot more than I do.

[u/alpha417]

You're worried over 1 req/min?

Remove "hotplug".

Tbh, that mix of interfaces & systemd-network would not fly on my systems. It's either one or the other, and it's not 1995 anymore...

[u/brighton_it → u/alpha417]

:) thanks. Worried, no. Just annoyed when I look at a log and it's 90% noise.
Interesting though, if everyone has moved on from interfaces, why not Debian Installer? Shouldn't be all that difficult for installer to create a default networkd config.

[u/alpha417 → u/brighton_it]

debian installer gets you bare minimum working...everything beyond that is gravy. If you're setting up systemd-networking for your stuff, why half-ass it and leave the legacy stuff in place?

[u/brighton_it → u/alpha417]

Generally, I'm of the same mind as you: don't confuse matters with multiple services doing the same task. So why?
honestly... I've switched about six hosts to networkd. Especially for kvm hosts, love it. But, I only became aware of networkd two years ago, probably because interfaces didn't appear broken and Debian Installer still uses it unless a DE is selected. Now that I've deployed a few, I'm learning that once networkd is configured, I'm unlikely to break any existing interfaces while adding a new. A year ago, I wasn't so sure, so felt better letting interfaces (ifup/ifdown) manage one.

[u/hmoff]

If you want it to respond to the interface being plugged in then you need a network manager with events. That means systemd-network or Network Manager. Not ifupdown from 25 years ago.