FS#11849 - /etc/conf.d/dhcpcd could be depreciated in favor of /etc/dhcpcd.conf

Attached to Project: Arch Linux
Opened by solsTiCe (zebul666) - Wednesday, 22 October 2008, 17:26 GMT
Last edited by Ronald van Haren (pressh) - Wednesday, 12 November 2008, 20:55 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Tom Killian (tomk)
Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


i just noticed that there is a /etc/dhcpcd.conf file now. and i need to use it to disable the dns server look up of dhcpcd. there is no more a --nodns switch

so why not use /etc/dhcpcd.conf instead of /etc/conf.d/dhcpcd
it's an idea. i have not investigated if it could be done on arch.

in fact all options in /etc/conf.d/dhcpcd by default are useless because there are the default used by dhcpcd
timeout is by default 30
hostname is by default the current hostname
noip4all could be set in /etc/dhcpcd.conf

as you see

This task depends upon

Closed by  Ronald van Haren (pressh)
Wednesday, 12 November 2008, 20:55 GMT
Reason for closing:  Implemented
Comment by Gerhard Brauer (GerBra) - Wednesday, 29 October 2008, 11:37 GMT
I vote for this. dhcpcd Version 4.x have some changes which IMHO could be better solved in /etc/dhcpcd.conf. We have currently many bugreports and forum posts about dhcpcd releated things.
Comment by Aaron Griffin (phrakture) - Wednesday, 29 October 2008, 14:03 GMT
I agree that this file now seems mostly useless.

Would someone be willing to search and update wiki documentation to mention this change?
Comment by Gerhard Brauer (GerBra) - Wednesday, 29 October 2008, 15:19 GMT
My english is not enough for this (i have done a quick search, seames to be a lot of references also in foreign language wiki pages.

We also should modify our /etc/rc.d/network script.
And have a look on the /etc/dhcpcd.conf options. With version 4 of dhcpcd AFAIK there is a major change in carrier/link handling. You could see this when on ethernet you remove your cable.
dhcpcd -d eth0:
It fails cause no carrier is detected, and it configured eth0 not with a IPv4LL/Zeroconf IP as some would assume when looking at the man page-> Local Link configuration.
dhcpcd -d -K eth0:
Disabling carrier status checking leads to the "normal" behavior: eth0 got an 169.254.x.x IP and dhcpcd forks to background and look if it could get a proper lease.

In our current /e/conf.d/dhcpcd.conf we use Option -L to disable Zeroconf handling (this was a feature request). But i think this is mostly usefull on the install ISO, to prevent the user from thinking: i have a network connection. On normal running systems i would prefer to leave Zeroconf enabled, but (with -K/nolink) we must make sure that the dhcpcd not got stopped if no carrier is available.
Also if we (or one) prefer to disable Zeroconf (-L/noipv4ll) there is a problem with V4 (when there is for some circumstands no link/carrier):
dhcpcd -d -L eth0:
No device config and dhcpcd fails and exits. No further tries.
dhcpcd -d -L -K eth0:
Also fails like above, although we disable carrier check with -K
Only solution for this (no link, but dhcpcd should wait for carrier but we don't want a Zeroconf IP) is:
dhcpcd -d -L -b eth0
That means dhcpcd should go immidiatly to background.

You see there are some things to check IMHO, as a result of version 4 we have a lot of problems in forum posts etc. The carrier/link problem appears to get often a problem on wireless, pcmcia ethernet cards or buggy routers.
Comment by Ronald van Haren (pressh) - Friday, 31 October 2008, 12:28 GMT
I'm not sure if it is a good idea to completely ditch /etc/conf.d/dhcpcd at the moment. As far as I can see not all command line arguments/options are supported by /etc/dhcpcd.conf at the moment. I'd prefer to have these (only these, options supported by /etc/dhcpcd.conf should go there) still in /etc/conf.d/dhcpcd for easy accessibility rather than modifying daemons.

Adding -b to DHCPCD_ARGS is imo not a very good solution as it returns always success just like ipv4all.
Comment by Ronald van Haren (pressh) - Tuesday, 04 November 2008, 09:07 GMT
I'll be moving dhcpcd 4.0.3 to extra shortly with above changes I mentioned. I'll leave this bug report open until some wiki pages are modified to incorporate the new way of configuring it.

If someone could step up and change the wiki entries (there are quite some I think) that would be great. If not I hope I come to it in the next couple of days.