-
Notifications
You must be signed in to change notification settings - Fork 884
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/dhcp: bump dhcpcd timeout to 300s #5127
Conversation
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this PR @cjp256. Matching dhclient timeout behavior is probably best.
There is no cloud-init controlled duration for the dhclient process as it doesn't fork and there is no timeout value passed to subp().
It does fork, but not until after the receiving an IP address. This is why we clean up the daemon.
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork until after it receives an IP address and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork until after it receives an IP address and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork until after it receives an IP address and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork until after it receives an IP address and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork until after it receives an IP address and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork until after it receives an IP address and there is no timeout value passed to subp(). I have seen some distros configure dhclient with a timeout of 60s, but is far less common. Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address. Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
On most distros, including Ubuntu, the default timeout for dhclient is 300s. There is no cloud-init controlled duration for the dhclient process as it doesn't fork and there is no timeout value passed to subp().
I have seen some distros configure dhclient with a timeout of 60s, but is far less common.
Given that a cloud VM is not very useful with DHCP, err on the generous side and allow up to 300 seconds for dhcpcd to get an address.
Note that there is still an issue with dhcpcd retries which will be addressed later in a separate PR.