Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC

Bug 417365

Summary: sys-apps/openrc: parameter "-1" passed to dhclient, causing dhclient not to retry when failing
Product: Gentoo Hosted Projects Reporter: lsching17
Component: netifrcAssignee: netifrc Team <netifrc>
Status: UNCONFIRMED ---    
Severity: normal CC: bkohler, bugs, kfm
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
Created attachment 312945 [details]
dhclient.conf

openrc-0.9.8.4
dhcp-4.2.3_p1

i have specified in "dhclient.conf" for timeout if no response from dhcp server after 5 second, and retry every 5 second.

However, dhclient simply exit after failure.

There is related discussion on gentoo forum

http://forums.gentoo.org/viewtopic-t-902194-start-0.html

i follow the instruction and remove the "-1" parameter at /lib64/rc/net/dhclient.sh line 49 (which request dhclient to exit immediately when fail) and the problem solved.

Please consider remove the parameter from the file.
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-05-25 21:34:53 UTC
The -1 should only be removed if the user has a retry option in their configuration I think.
Comment 2 William Hubbs gentoo-dev 2012-06-07 06:37:00 UTC
@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?
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-06-07 16:01:37 UTC
I vote to add a setting to conf.d/net for users that need to override it.
Comment 4 William Hubbs gentoo-dev 2012-06-07 18:24:57 UTC
(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.
Comment 5 lsching17 2012-06-08 23:37:00 UTC
(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
Comment 6 William Hubbs gentoo-dev 2012-06-09 02:52:14 UTC
(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.
Comment 7 lsching17 2012-06-09 23:31:20 UTC
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.
Comment 8 William Hubbs gentoo-dev 2012-06-10 21:42:52 UTC
(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.
Comment 9 lsching17 2012-12-07 11:49:41 UTC
this problem also exists in openrc 0.11.6
Comment 10 cilly 2015-06-18 11:00:52 UTC
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
Comment 11 cilly 2015-06-18 11:03:06 UTC
Created attachment 405320 [details, diff]
netifrc remove "-1" from dhclient.sh
Comment 12 cilly 2015-06-18 11:10:14 UTC
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.
Comment 13 Mihai Moldovan 2020-05-22 11:55:15 UTC
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.
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-05-31 05:15:26 UTC
*** Bug 688352 has been marked as a duplicate of this bug. ***