Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 400845 - sys-apps/openrc-0.9.8.4 - race during network interface configuration
Summary: sys-apps/openrc-0.9.8.4 - race during network interface configuration
Status: IN_PROGRESS
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: netifrc (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: netifrc Team
URL:
Whiteboard: netifrc:system
Keywords:
: 406139 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-26 00:43 UTC by Alon Bar-Lev
Modified: 2015-01-12 14:03 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alon Bar-Lev 2012-01-26 00:43:43 UTC
sys-apps/openrc-0.9.8.1
net-dialup/ppp-2.4.5-r1
net-dns/openresolv-3.4.1

From what I see the ppp ip-up script is working OK, the resolvconf is called with correct settings.
But then the net.ppp0 is calling resolv conf again with empty configuration overriding the ppp settings.

Result is empty resolv.conf settings.

I do see the following in messages, not sure it should be there, after pppd is up:
Jan 26 02:21:30 localhost /etc/init.d/net.ppp0[19894]: status: inactive
Comment 1 Alon Bar-Lev 2012-01-26 09:39:46 UTC
As far as I know openrc should not call resolvconf in this configuration
---
Jan 26 02:34:44 localhost /etc/init.d/net.ppp0[23000]: status: inactive
Jan 26 02:34:44 localhost nobody: RESOLV 23004 -a ppp0
Jan 26 02:34:44 localhost nobody: root     23004 23001  0 02:34 ?        00:00:00 /bin/sh /lib64/rc/sh/runscript.sh /etc/init.d/net.ppp0 start
Jan 26 02:34:44 localhost nobody: root     23130 23004  0 02:34 ?        00:00:00 /bin/sh /sbin/resolvconf -a ppp0
---
Comment 2 Alon Bar-Lev 2012-01-26 09:42:20 UTC
/etc/conf.d/net
---
dns_options="edns0" # large payload

rc_need_ppp0="firewall bluetooth"
config_ppp0="ppp"
link_ppp0="/dev/rfcomm0"
username_ppp0=''
password_ppp0=''
phone_number_ppp0="*99#"
pppd_ppp0="noauth defaultroute usepeerdns lock mru 296 mtu 296"
---
Comment 3 Alon Bar-Lev 2012-01-27 18:42:31 UTC
The "oldnet" is the *BEST* networking support and configuration among *ALL* Linux distributions!

Not sure what the old term means... I know Roy wanted to remove this, but that move was insane.
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-02-09 09:57:43 UTC
"newnet" is going away. I only support oldnet.

I don't use openresolv however, so you're going to need to dig deeper.
Comment 5 Alon Bar-Lev 2012-02-09 10:04:10 UTC
(In reply to comment #4)
> "newnet" is going away. I only support oldnet.

Good to hear!

> I don't use openresolv however,

Maybe I miss something...
How do you manage DNS change of dhcpcd, ppp, vpn without openresolv? Is there another solution to coordinate between these, keeping system sane?

> so you're going to need to dig deeper.

Will do.
Comment 6 Alon Bar-Lev 2012-08-14 09:16:32 UTC
Hello,

Had some time to figure this out, this is not ppp specific issue.

The problem is that global DNS options, these without interface suffix are processed for all interfaces, hence if exist override any external configuration put by ppp, dhcp, openvpn etc.

Assuming the following /etc/conf.d/resolv.conf
---
dns_options="edns0"
config_eth0="dhcp"
---

Two dns configurations are generated for the same interface, one by openrc and one by dhcpd.

openrc (/lib/rc/net/system.sh::_system_dns):
---
edns0
---

dhcpd (/lib64/dhcpcd/dhcpcd-hooks/20-resolv.conf):
---
nameserver 10.200.0.245
---

Now we have a race between the two, last wins.

I am not sure what is a proper fix... maybe merge and not replace.

Temporary workaround should be to specify options for the lo interface, this will be added as constant.

Setting at global that cause the above behavior.
- dns_servers
- dns_domain
- dns_search
- dns_sortlist
- dns_options

Why didn't we see this until now?

I guess because dhcp usually sets dns configuration after openrc sets, so people always got the dhcp configuration.

I found this when ppp was used, as the sequence is different, but it applies to all cases.

Alon
Comment 7 Ian Stakenvicius (RETIRED) gentoo-dev 2013-08-28 19:31:48 UTC
(In reply to Alon Bar-Lev from comment #6)
> Why didn't we see this until now?


I ran into this the other day, too, but across different interfaces while using plain old /etc/resolv.conf.  I'm quite sure that this didn't happen before (ie, setting dns_domain="something.lan" did not automatically mean starting an iface always overwrote /etc/resolv.conf).

I expect this 'race' may be related somehow to the fact that 'net' is no longer provided by 'net.lo' and the global options are provided when 'net' is first started or available...
Comment 8 Sergey Popov (RETIRED) gentoo-dev 2015-01-10 18:19:30 UTC
*** Bug 406139 has been marked as a duplicate of this bug. ***
Comment 9 Martin Mokrejš 2015-01-12 13:32:54 UTC
While reading this I think it could be also an issue with vpnc connections I faced in the past (and cannot say whether they are still present).

Here is my observation. Provided I had running connection with whatever DNS values I obtained via DHCP, if I lost a physicial eth link (just pull out the etehrnet cable for more then 5 seconds or so) then my resolv.conf used to be emptied, or at least overwritten by some old backup values from setup before I connected via vpnc. Basically, although vpnc worked after the cable was re-plugged in, the DNS was screwed.
Comment 10 Alon Bar-Lev (RETIRED) gentoo-dev 2015-01-12 13:34:52 UTC
(In reply to Martin Mokrejš from comment #9)
> Here is my observation. Provided I had running connection with whatever DNS
> values I obtained via DHCP, if I lost a physicial eth link (just pull out
> the etehrnet cable for more then 5 seconds or so) then my resolv.conf used
> to be emptied, or at least overwritten by some old backup values from setup
> before I connected via vpnc. Basically, although vpnc worked after the cable
> was re-plugged in, the DNS was screwed.

do you have openresolv installed?
Comment 11 Martin Mokrejš 2015-01-12 13:57:04 UTC
(In reply to Alon Bar-Lev from comment #10)
> (In reply to Martin Mokrejš from comment #9)
> > Here is my observation. Provided I had running connection with whatever DNS
> > values I obtained via DHCP, if I lost a physicial eth link (just pull out
> > the etehrnet cable for more then 5 seconds or so) then my resolv.conf used
> > to be emptied, or at least overwritten by some old backup values from setup
> > before I connected via vpnc. Basically, although vpnc worked after the cable
> > was re-plugged in, the DNS was screwed.
> 
> do you have openresolv installed?

Yes, at the moment version 3.5.6. Ideally I would have to lookup some "emerge --info" output in Gentoo bugzilla from about 2012. I failed to search for the "emerge --info" in Comments. :(

While browsing through vpnc bugs I was involved in, let me at least point you to a bug that vpnc did not restore resolv.conf upon its exit (bug #406141), so a different issue. When thinking of teh possible scenarios, maybe of interest is #424529. I think it is easier to tryu to test some setups, I know I have been trying ifplugs and netplugd but as I had no good insight into the net/openrc configuration tool and config file variables, I could not distill much out the of behavior. So, just a clue how to "repeat" at least similar issues.
Comment 12 Alon Bar-Lev (RETIRED) gentoo-dev 2015-01-12 14:03:18 UTC
(In reply to Martin Mokrejš from comment #11)
> While browsing through vpnc bugs I was involved in, let me at least point
> you to a bug that vpnc did not restore resolv.conf upon its exit (bug
> #406141), so a different issue. When thinking of teh possible scenarios,
> maybe of interest is #424529. I think it is easier to tryu to test some
> setups, I know I have been trying ifplugs and netplugd but as I had no good
> insight into the net/openrc configuration tool and config file variables, I
> could not distill much out the of behavior. So, just a clue how to "repeat"
> at least similar issues.

I think this specific bug is with ppp handling.