| Summary: | sys-apps/openrc: parameter "-1" passed to dhclient, causing dhclient not to retry when failing | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | lsching17 |
| Component: | netifrc | Assignee: | netifrc Team <netifrc> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | bkohler, bugs |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | netifrc:dhclient | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
dhclient.conf
netifrc remove "-1" from dhclient.sh |
||
|
Description
lsching17
2012-05-24 11:59:56 UTC
The -1 should only be removed if the user has a retry option in their configuration I think. @robbat2:
Timeouts or retries can be either defined globally or per interface. In
the attached example they are defined globally, but they can go in an
interface { ... } section so they only apply to a specific interface.
So, in order to do this automatically we would need to parse the
dhclient.conf file ourselves.
Another method would be to add a dhclient-specific setting to
/etc/conf.d/net to control whether the "-1" is added to the arguments or not.
What are your thoughts?
I vote to add a setting to conf.d/net for users that need to override it. (In reply to comment #3) > I vote to add a setting to conf.d/net for users that need to override it. Do you know why we force dhclient to exit to begin with? looking at the other dhcp provider modules, I don't see us forcing the other clients to exit. (In reply to comment #2) > @robbat2: > Timeouts or retries can be either defined globally or per interface. In > the attached example they are defined globally, but they can go in an > interface { ... } section so they only apply to a specific interface. > > So, in order to do this automatically we would need to parse the > dhclient.conf file ourselves. > > Another method would be to add a dhclient-specific setting to > /etc/conf.d/net to control whether the "-1" is added to the arguments or not. > > What are your thoughts? Hello developers, As the problem reporter, i suggest to allow user to specify the "dhclient.conf" rather than a retry option in conf.d/net e.g. dhclient_config_eth0="/etc/dhcp/dhclient_ipv4.conf" 1. The retry option of conf.d/net will be broken if upstream provides more sophicated retry parameter like "maximum number of retry before failure" 2. The requirement of each network interface may be different and requires different dhclient.conf e.g. ipv4, ipv6, lease, reject, dhcp-lease-time (In reply to comment #5) > Hello developers, > > As the problem reporter, i suggest to allow user to specify the > "dhclient.conf" rather than a retry option in conf.d/net > > e.g. dhclient_config_eth0="/etc/dhcp/dhclient_ipv4.conf" > > 1. The retry option of conf.d/net will be broken if upstream provides more > sophicated retry parameter like "maximum number of retry before failure" > 2. The requirement of each network interface may be different and requires > different dhclient.conf e.g. ipv4, ipv6, lease, reject, dhcp-lease-time There is no need to have separate dhclient.conf files for each interface. You can use interface statements in the dhclient.conf file to configure each interface. i don't realize that, but it seems that(In reply to comment #6) > (In reply to comment #5) > > Hello developers, > > > > As the problem reporter, i suggest to allow user to specify the > > "dhclient.conf" rather than a retry option in conf.d/net > > > > e.g. dhclient_config_eth0="/etc/dhcp/dhclient_ipv4.conf" > > > > 1. The retry option of conf.d/net will be broken if upstream provides more > > sophicated retry parameter like "maximum number of retry before failure" > > 2. The requirement of each network interface may be different and requires > > different dhclient.conf e.g. ipv4, ipv6, lease, reject, dhcp-lease-time > > There is no need to have separate dhclient.conf files for each interface. > You can use interface statements in the dhclient.conf file to configure each > interface. i don't realize that the interface section is capable for this, but it seems that not all option can be put in interface statement. (In reply to comment #7) > (In reply to comment #6) > > There is no need to have separate dhclient.conf files for each interface. > > You can use interface statements in the dhclient.conf file to configure each > > interface. > > i don't realize that the interface section is capable for this, but it seems > that not all option can be put in interface statement. According to the dhclient.conf man page, the only things you can't put in the interface section are lease { ... } and alias { ... } declarations. However, I did find another issue with listing interfaces in the dhclient.conf file: " Note well: ISC dhclient only maintains one list of interfaces, which is either determined at startup from command line arguments, or otherwise is autodetected. If you supplied the list of interfaces on the command line, this configuration clause will add the named interface to the list in such a way that will cause it to be configured by DHCP. Which may not be the result you had intended. This is an undesirable side effect that will be addressed in a future release. " This tells me that if you have multiple dhclients running, (which is very possible with these scripts) and you use the interface { ... } section in dhclient.conf, you may have more than one dhclient trying to configure the same interface. So I have to take back my suggestion for using the interface declaration if you are running dhclient with the net.* scripts. this problem also exists in openrc 0.11.6 The problem still persists with:
sys-apps/openrc-0.16.4, and
net-misc/netifrc-0.2.2
Even setting the following in /etc/conf.d/net won't help:
dhclient_{iface}="-w -nw"
The setting is hardcoded into the following file:
/lib/netifrc/net/dhclient.sh
There are several usage-cases, where the dhclient should stay alive, i.e. if the dhcpd on the other side is down, or unreachable and will come up later.
Meanwhile I wrote a patch for netifrc-0.2.2 to remove -1 completely which might help others stepping into the same issue. The patch can be placed into: /etc/portage/patches/net-misc/netifrc/ and will then be applied automatically while emerging netifrc.
Good Luck & Have Phun
Created attachment 405320 [details, diff]
netifrc remove "-1" from dhclient.sh
Comment on attachment 405320 [details, diff]
netifrc remove "-1" from dhclient.sh
This patch does not solve the issue. This is only a patch for those who need to have -1 removed immediately. This patch is seen as a dirty temporary solution.
In #688352, the reporter mentioned that this behavior could be classified as a bug and potentially be reported upstream. I'm a bit split regarding this, because there are good arguments for both "bug" and "no bug" groups. The parameter is explicitly documented as "Try to get a lease once". If the discovery times out, then that would theoretically mean that the lease is done and continuing would fetch... a new lease. Not exactly the idea of "once". Then again, strictly speaking, it already does so. If the lease can't be extended via DHCPREQUEST, it seems to issue DHCPDISCOVER messages until it either runs in a timeout or can successfully... do something. This sounds a bit weird, but maybe it's a valid continuation of the "once" part: if the DHCPDISCOVER broadcast is answered with an DHCPOFFER message containing the last lease's IP address, then re-taking it sounds sane. Failing in error cases also sounds sane in a one-shot mode. Additionally, a true one-shot mode would be stupid, since it would mean fetching a lease and never renewing it (at least if you'd take one-shot/once by the word). Also, and interestingly, other distros are also running into this issue, for instance Ubuntu at https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1196975 . Note how they even patch dhclient to remove the initial timeout, but not the fail-exit stuff. I don't quite get Ubuntu's approach to this whole business anyway. Patching out the initial timeout essentially degrades the -1 option into... well, not using the -1 option altogether. It's pretty much the whole point of the option to make dhclient fail if no lease could be obtained. All this siad, it might be worthwhile to request an additional option to dhclient. Gentoo/netifrc doesn't really want to use an one-shot mode. Instead, what you want seems to be the initial timeout/exit on timeout behavior without subsequent exits. I don't think that netifrc would mine if the actual address were to change either. *** Bug 688352 has been marked as a duplicate of this bug. *** |
