You are not logged in.

#1 2014-05-16 20:42:58

jsnlry
Member
Registered: 2012-06-26
Posts: 39

[SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

Hi, I have big troubles with my dhcpcd/NetworkManager configuration. Basically dhcpcd constantly overwrites my /etc/resolv.conf file.

For debugging this problem I disabled NetworkManager and dhcpcd with these commands:

systemctl disable networkmanager
systemctl disable dhcpcd

But when I restart the computer, I can still find a dhcpcd process:

# ps aux | grep dhcp
root       553  0.0  0.0   8648   424 ?        Ss   22:29   0:00 /usr/bin/dhcpcd -q -w eth0

Is this correct? Where does this process come from? As soon as I kill it, everything's fine.

Last edited by jsnlry (2014-05-19 06:47:18)

Offline

#2 2014-05-16 21:09:47

Raynman
Member
Registered: 2011-10-22
Posts: 1,539

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

You probably have dhcpcd@eth0.service enabled. Looking at

# systemctl --type=service

should help to find running/enabled services. When you've disabled everything, pick one network service to (re-)enable.

Offline

#3 2014-05-16 22:07:33

headkase
Member
Registered: 2011-12-06
Posts: 1,983

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

If what you want in your resolv.conf doesn't change then you can make the file immutable:

sudo chattr +i /etc/resolv.conf

And undo that with:

sudo chattr -i /etc/resolv.conf

Immutable files cannot be changed by anything, even root.  You actually have to make the file mutable again for root to do anything too.

Offline

#4 2014-05-16 22:12:52

headkase
Member
Registered: 2011-12-06
Posts: 1,983

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

Also, see: https://wiki.archlinux.org/index.php/Resolv.conf
For everything to do with that.  Making it immutable is on that page even.

Offline

#5 2014-05-16 22:36:35

jsnlry
Member
Registered: 2012-06-26
Posts: 39

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

@Raynman Yes. I think that was it. Don't want to reboot and test now because I am connected via SSH, but I'll keep you informed.

Offline

#6 2014-05-17 07:48:16

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

jsnlry wrote:

overwrites my /etc/resolv.conf file.

Use e.g.:

dhcpcd -C resolv.conf -l 86400 wlan

Better still, scrap dhcpcd in favour of busybox (see link in my sig):

udhcpc -i wlan -S -x lease:86400

Offline

#7 2014-05-17 14:34:18

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

What does udhcpc do that dhcpcd doesn't, or is there a specific reason you don't like dhcpcd?

Offline

#8 2014-05-17 17:07:09

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

rsmarples wrote:

specific reason

Hello, author wink

dhcpcd already felt bloated, but it was the overwriting, by *default*, of /etc/resolv.conf (a hugely important system file) that made me pursue an alternative.

Overwriting /etc/resolv.conf should require an option to *enable* that feature, I reckon.

Plus, I'm quite a Busybox fanboy, favouring software that's simple and easily tweakable.

Offline

#9 2014-05-17 17:20:18

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

BLOATED. lol

it's 155k on i386 which is quite tiny for what it does.
dhcpcd has an option to disable that feature. DHCP clients are kind of expected to configure an IP address and DNS servers. just an IP address is half of the deal.
Luckily it has an option to disable it! Or you can just chmod +i it as others have pointed out.

But wake me up when udhcpc deals with link states, ARP checking, etc. People expect more than just DHCP these days wink

Offline

#10 2014-05-17 18:19:13

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

rsmarples wrote:

Or you can just chmod +i it

Since I package it myself, I removed the naughty hook:

mv -v /usr/libexec/dhcpcd-hooks/20-resolv.conf /usr/share/doc/dhcpcd/

Not a problem, *after* I figured out which daemon is modifying a system configuration file behind my back wink

link states

That reminds me of a "proper" difference. Back when I was using dhcpcd - it would make the interface go down, during the 10-ish seconds that my router would take to renew its 12-hour lease. Which seemed like a reasonable, minor annoyance, until I noticed that udhcpc didn't have these snippets of Internet unavailability wink

Offline

#11 2014-05-17 19:18:07

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

brebs wrote:
rsmarples wrote:

Or you can just chmod +i it

Since I package it myself, I removed the naughty hook:

mv -v /usr/libexec/dhcpcd-hooks/20-resolv.conf /usr/share/doc/dhcpcd/

Not a problem, *after* I figured out which daemon is modifying a system configuration file behind my back wink

It's hardly behind your back, it's fully documented and the upstream busybox scripts do create it as well.
http://git.busybox.net/busybox/tree/exa … mple.bound

link states

That reminds me of a "proper" difference. Back when I was using dhcpcd - it would make the interface go down, during the 10-ish seconds that my router would take to renew its 12-hour lease. Which seemed like a reasonable, minor annoyance, until I noticed that udhcpc didn't have these snippets of Internet unavailability wink

OK, udhcpc is just like any other DHCP client available for our OS's - it's just a DHCP client. So when the link goes down, the address persists.
At this point it's still fine, but the bad news is that the address and lease persist when the link comes back up again. Now for a home setup where the link never changes this is not a problem, but there is no guarantee from dhcpcds perspective that the network hasn't changed.
Also, having an invalid IP on a different network isn't very nice from the perspective of the new network, so dropping the address is the correct thing to do. The good news is that dhcpcd will re-negotiate an address on the new network and get things moving again. Something which udhcp doesn't do by default and I'm pretty sure that only Gentoo net.* scripts can actually control udhcp in this manner. You'll see the Linux kernel doing this with IPv6 addresses as well so the behavior is hardly new. Such a good idea I made the NetBSD kernel do it also wink

Again, this is a good default behaviour, especially as dhcpcd is used on Android by default and I for one change across many wireless networks when I'm working in London.
But, as you point out, this might not be good for your setup - which is why dhcpcd comes with the ever handy --nolink option to ignore link carrier events. This is of course all documented in dhcpcd(8) and dhcpcd.conf(5).

Offline

#12 2014-05-17 20:06:29

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

rsmarples wrote:

the upstream busybox scripts do create it as well.
http://git.busybox.net/busybox/tree/exa … mple.bound

No, that's a different file, in the URL you point to:

RESOLV_CONF="/etc/udhcpc/resolv.conf"

Not that I've ever used it.

--nolink option

Great smile

Offline

#13 2014-05-17 22:55:34

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

brebs wrote:
rsmarples wrote:

the upstream busybox scripts do create it as well.
http://git.busybox.net/busybox/tree/exa … mple.bound

No, that's a different file, in the URL you point to:

RESOLV_CONF="/etc/udhcpc/resolv.conf"

/facepalm

Offline

#14 2014-05-18 08:02:55

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

/etc/resolv.conf is a system file, and mine contains nameserver 127.0.0.1 to use BIND, and no system daemons should overwrite that by default.

/etc/udhcpc/ is a safe area for daemon-specific files. But "resolv.conf" is there, I hear you say. So what?

I was hoping that this distinction between a system file and a daemon-specific file (which doesn't even get used unless I set it up) would be obvious sad

I shall go on using and recommending udhcpc, thanks. I've tweaked my script to kill & restart wpa_supplicant in the "leasefail" section, as simple link reconnection management.

so dropping the address is the correct thing to do

So, you're saying that having occasional network dropout, on a network that works fine, is a *good* thing? That sure sounds wrong.

How about instead, the protocol says, "the link will die after 2 more minutes, so let's do some handshaking to extend the lease time *now*, while it's all still working."

Surely that's better than, "As the router, I've just killed your Internet connectivity immediately, now let's renegotiate so you can get a functioning network back." wink

Offline

#15 2014-05-18 13:22:55

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

brebs wrote:

/etc/resolv.conf is a system file, and mine contains nameserver 127.0.0.1 to use BIND, and no system daemons should overwrite that by default.

/etc/udhcpc/ is a safe area for daemon-specific files. But "resolv.conf" is there, I hear you say. So what?

I was hoping that this distinction between a system file and a daemon-specific file (which doesn't even get used unless I set it up) would be obvious sad

Just saw this file which is what I was used to, hence me thinking that udhcpc does write to /etc/resolv.conf
http://git.busybox.net/busybox/tree/exa … ple.script

/ec/resolv.conf isn't a daemon specific file, you rightly point out it's a system file.
However, by starting the Dynamic Host Configuration Protocol it will by default, Configure the Host Dynamically according to the Protocol.
If the Protocol specifies DNS servers then a good client will configure DNS servers as dictated by the Protocol.
The problem here is that the only standard place to configure DNS is resolv.conf.
Out of the box, very few if any (please correct be if I'm wrong) distributions have a local DNS resolver other than libc installed and configured by default.

So, a condrum.
A user would rightly expect dhcpcd to configure the network connection for them by default, and also rightly expect working DNS.
A conundrum indeed as I don't know of another way of managing it.

Also, this problem isn't unique to DHCP clients -  IPv6, PPP and VPN clients have DNS information too.
What do they do? Other implementations also write to resolv.conf, generally out of the box. But luckily they all have an option to turn this off, as does dhcpcd.

To make it more interesting, what happens when you have >1 thing trying to write to this system file? Quite messy indeed, but not uncommon these days when laptops have wired, wireless and maybe a VPN connection as well.
Luckily there is a semi stand way of managing this - resolvconf.
http://en.wikipedia.org/wiki/Resolvconf
At lot of things that would normally write to /etc/resolv.conf now write to resolvconf(8) if available and do it by default out of the box.

Both resolvconf implementations can be configured not to touch the /etc/resolv.conf at all as well.

I think we've argued this point into the ground now. I believe that DHCP should configure working DNS according to the protocol by default and you don't so lets drop it and move on.

I shall go on using and recommending udhcpc, thanks.

That's fine, I cannot force you to change but I will also recommend using dhcpcd if you don't mind wink

I've tweaked my script to kill & restart wpa_supplicant in the "leasefail" section, as simple link reconnection management.

So basically you're saying "When a DHCP lease fails or expires, try and reconnect to a different access point I have configured".
Interesting. Not sure I would want to do that in dhcpcd though as wpa_supplicant can manage it's access point association fine for me and restarting it generally doesn't make it magically work again, whereas moving slightly to avoid a brick wall would.

so dropping the address is the correct thing to do

So, you're saying that having occasional network dropout, on a network that works fine, is a *good* thing? That sure sounds wrong.

How about instead, the protocol says, "the link will die after 2 more minutes, so let's do some handshaking to extend the lease time *now*, while it's all still working."

Surely that's better than, "As the router, I've just killed your Internet connectivity immediately, now let's renegotiate so you can get a functioning network back." wink

The kernel says the link is down, you don't have connectivity even if you keep the address - and trust me, the kernel, PPP and VPN clients go out of their way to keep the link up and I think they all have confguration options to say "tell kernel to notify link down after N seconds of no response"
Also, how can we possibly know this in advance OR do any handshaking to extend the lease if there's nothing to handshake to at the other end?

Lastly, by NOT dropping the address you are adding latency to the client (or clients through the router) by fooling them into thinking the route is still up. Much better to get a fast network down error or host unreachable error rather than waiting and waiting and waiting and finally timeout. This is why the kernel and PPP clients like to remove the address - dhcpcd plays along by dropping the address also. And as we discussed earlier this is configurable also.

If you still think this sounds wrong, can you propose a better solution?

Offline

#16 2014-05-18 15:31:32

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

rsmarples wrote:

A user would rightly expect dhcpcd to configure the network connection for them by default, and also rightly expect working DNS.

Yup. Which is why I'm not calling it a bug wink

udhcpc has a slight advantage here, in that we *have* to modify its script, to get it working, and so any reference to /etc/resolv.conf is blatantly obvious.

"When a DHCP lease fails or expires, try and reconnect to a different access point I have configured"

It's a quick-and-unclean method that seems to work fine. I haven't delved to see whether the problem lies in wpa_supplicant, or dhcp.

you don't have connectivity even if you keep the address

I *did* still have connectivity for those 10-ish seconds (after I switched to udhcpc - I never tried dhcpcd's --nolink option), so we may be talking about slightly different issues.

My point was that, for imminent lease expiry, the lease renegotiation should occur *before* the lease expires, rather than after, so that network connectivity is not interrupted wink

Last edited by brebs (2014-05-18 15:35:44)

Offline

#17 2014-05-18 16:38:54

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

brebs wrote:
rsmarples wrote:

you don't have connectivity even if you keep the address

I *did* still have connectivity for those 10-ish seconds (after I switched to udhcpc - I never tried dhcpcd's --nolink option), so we may be talking about slightly different issues.

My point was that, for imminent lease expiry, the lease renegotiation should occur *before* the lease expires, rather than after, so that network connectivity is not interrupted wink

lease renegotiation happens before it expires. DHCP supplies lease lifetime and T1 and T2.
When T1 is reached, a RENEW occurs. This causes dhcpcd to send unicast REQUEST messages to the DHCP server every few seconds, slowly backing off up to a minute. This happens until T2 is reached and REBIND occurs. We reset the backoff timer and broadcast REQUEST messages for our lease every few seconds backing off up to a minute.
When lease expires, the address is dropped and dhcpcd re-enters the DISCOVER phase to find a new address.

So it should work fine.

Let us assume for a minute you previously hit a bug in dhcpcd which affected timings. Can you re-test it please?

Offline

#18 2014-05-19 06:51:05

jsnlry
Member
Registered: 2012-06-26
Posts: 39

Re: [SOLVED] dhcpcd constantly overwrites my /etc/resolv.conf

My problem is solved. Thanks to @Rainman who gave the first answer!

Offline

Board footer

Powered by FluxBB