Project

General

Profile

Actions

Bug #4408

closed

Changes to DHCP-services crashes GUI and DHCP daemon when many leases are in use

Added by Lars Jorgensen about 9 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
DHCP (IPv4)
Target version:
-
Start date:
02/11/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:
amd64

Description

I have the DHCP service running on five interfaces and a good amount of leases (I would guess around 1,000 or more at any given time). If I make changes to the DHCP service while it is running, the pfSense GUI hangs indefinetely. I tried to run top on the box and can initially see two php-fpm processes each consuming a full core. After a while one of them dies but the other continues to run at full blast. Meanwhile the GUI is totally unresponsive.

I let it run for a bit longer and noticed that the DHCP service was crashed on the box.

I used to be able to stop the DHCP service and then make the changes, but this no longer seems to work. Today I tried to add a static mapping to one of the scopes and now I can't apply that change without crashing the GUI, even when the DHCP service is stopped.

I'm running in a CARP setup with DHCP failover enabled.

Actions #1

Updated by Lars Jorgensen about 9 years ago

If I disable DHCP failover everything works perfectly.

Actions #2

Updated by Patrick S about 9 years ago

I have similar problems since I updated from version 2.0 to 2.1, when I change something in the DHCPd settings I see the same behavior as you.
But in addition, when I change something DHCP independent, e.g. Rules or DNS Host Overrides, most of the Failover Groups switch to the "recover" state on the slave maschine.
It doesn't switch back to "normal" or "recover-wait" until I restart the DHCPd on the slave.

Actions #3

Updated by Chris Buechler over 8 years ago

  • Category set to DHCP (IPv4)
Actions #4

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Closed

This was most likely from the duplicate lease cleanup which was removed years ago in 306b9d003078f40999d352803e998867ebbc5086

Actions

Also available in: Atom PDF