isc-dhcp-server does not listen network interfaces

Bug #1772941 reported by Rafael Aybar
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
isc-dhcp (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

System: Ubuntu 16.04.4 LTS x64 XFCE desktop
Version of package: isc-dhcp-server
Uname: 4.4.0-127-generic
Result spected: service isc-dhcp-server status returning that service is active, running and OK.
Network interfaces: 2, enp0s3 (static, main), en0s8 not configured yet.
Current result:
service isc-dhcp-server status returns an error message, which says that there is no network interface listening.

In /etc/default/isc-dhcp-server I have configured this line:
INTERFACES="enp0s3" but still giving the same error. Links to an ask ubuntu question:https://askubuntu.com/questions/536531/dhcp-server-wont-start-gives-not-configured-to-listen-on-any-interfaces-eve

Tags: dhcp server
Revision history for this message
Wladimir Mutel (mwg) wrote :

On my system (Ubuntu 18.04 configured with netplan.io and systemd-networkd where possible), dhcpd is configured by default, so it just enumerates currently-available IP subnets on interfaces to determine on which interface to listen.
The only interface it is normally listening on my system is br0, which currently includes only wlan0 interface managed by hostapd.
On one reboot I had a race condition between dhcpd and hostapd : on its startup, hostapd did 'country update' on wlan0 which temporarily brought it down, and br0 went down as well, then systemd-networkd temporarily removed its IP address. Right at this moment, dhcpd had begun to start, looking matching IPs on interfaces and failing to find any of them. After that I got working hostapd (WiFi network visible to clients), but clients unable to configure their IPs after WiFi authentication.

So, yes, 'sleep 30' can be a solution, but it is better to implement some dependency on the systemd level. Like, start dhcpd not earlier than hostapd is started and operating. Or maybe start hostapd not earlier than dhcpd has found its subnet and interface (if dhcpd is capable to survive through temporary drop-down of its interface during normal operation).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in isc-dhcp (Ubuntu):
status: New → Confirmed
Revision history for this message
padarjohn (john-meissen) wrote :

It's getting to the point that I'm afraid to do updates on my Ubuntu servers anymore. :-(
I haven't had time to investigate more thoroughly, but it looks like dhcpd is being run before the network is up.
I'm running 14.04 LTS, and applied pending updates yesterday. When the system rebooted I ran into this. The system has a manually configured static IP address on a hardwired ethernet port. There's nothing wrong with the config file, in spite of the error message.
After getting past the fact that I suddenly also couldn't directly run the init script anymore (grrrr) and the obfuscation involved in trying to get initctrl to actually work, I was able to restart the service without issue.
I now have a server that I can't trust to boot unattended. This isn't acceptable.

Revision history for this message
Karim BAKKAL (kabak-85) wrote :

I think i have the same issue.
Ubuntu 18.04.5 i386 with two NIC and configured in order to listen and serve lease on a specific NIC.

After the boot procedure, the service fail.
If i make a restart without changing anything it's work.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.