Bug #3797
closed
DHCP server restarted multiple times on secondary after config sync
100%
Description
dhcpd is restarted twice on the secondary system after every config sync. In at least some circumstance (ticket MPG-56559), it restarts 4 times on the secondary on each config sync. That may be specific to use of static ARP w/DHCP, haven't had a chance to fully test that theory.
Where running DHCP failover, which is most cases with config sync, restarting dhcpd multiple times back to back seems to occasionally cause both instances of dhcpd to get stuck in odd states that don't return to normal/normal. Keeping it to a single restart seems to be fine. Restart it several times in quick succession, and it breaks failover status.
Updated by Renato Botelho about 10 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 85b3c597865c13cc7c6253332936ac266c74f164.
Updated by Renato Botelho about 10 years ago
Applied in changeset 7486c1f6c1951435b98d30b0533496065c826f9b.
Updated by Jim Pingle about 10 years ago
- Status changed from Feedback to New
There is still a problem here, it is still getting restarted multiple times but it appears to be due to this behavior:
On the primary: Create or edit a static mapping, press Save
- At this point, dhcpd is restarted on the secondary due to the config sync
On the primary: Press Apply changes
- At this point, dhcpd is restarted on BOTH nodes, and the problem recurs.
It should only restart on the secondary during one of those actions, not both, but both actions are resulting in a config and filter sync.
Updated by Renato Botelho about 10 years ago
- Status changed from New to Feedback
Applied in changeset 565488c9cf34c60eccf0f364acc8a0372af31569.
Updated by Renato Botelho about 10 years ago
Applied in changeset e5b3335ad921e072f20f052fd0e02a43aada700d.
Updated by Chris Buechler about 10 years ago
- Status changed from Feedback to Resolved
this looks to be fine, scenarios that previously triggered multiple restarts on the secondary now only have it restart once. That also worked around whatever bug(s) we were triggering within dhcpd's failover by restarting the service repeatedly on the secondary.