Comment 3 for bug 1849502
Revision history for this message
| Rodolfo Alonso (rodolfo-alonso-hernandez) wrote | #3 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi Slawek:
The problem is very similar (if not the same), but the root cause described and the patches submitted are completely different.
In 1848738, the problem you are describing is due to the subnet (dhcp-range) tag assignation. In this bug description, the problem I see is a race condition between the moment the server is spawned and the moment this same dnsmas process is restarted again because there is a subnet change. Actually the problem is between the moment the DHCP agent tries to stop it and when the agent tries to start it again:
- Agent tries to stop it, but does not find the PID or the process running. The process then is not stopped.
- Agent tries to start the process (350 ms later), but at this moment, the process is active and the agent (using ProcessManager) does nothing because considers that the dnsmasq process is running and there is no need to execute the command
===> this will lead us to the problem we have: the dnsmasq process does not restart with the new subnet configuration (new added subnets) and the --dhcp-range parameters won't be updated.
Regards.