I noticed that lately my squid failed to forward requests to a parent proxy. I found this line in my squid cache log: Configuring Parent ... WARNING: DNS lookup for '...' failed! Looking at my /var/log/rc.log (rc_logger="YES" in /etc/rc.conf) I found that recently my dhcpcd would detach, where it used to wait for an IP before: * Bringing up interface eth0 * No configuration specified; defaulting to DHCP * dhcp... * Running dhcpcd... dhcpcd: version 5.1.2 starting dhcpcd: no interfaces have a carrier dhcpcd: forking to background [ ok ] It seems that squid doesn't retry configuring a parent proxy if the request failed once, so an incomplete network interface at startup time makes the whole daemon unusable until root restarts it. Looking at the init script for squid, it indicates a dependency on net. So I guess that the init process now assumes that net is up after dhcpcd has backgrounded. I wouldn't be surprised if other init scripts would make the same assumption, and thus fail as well. Oh, by the way, all of this is due to changes in behaviour for dhcpcd 5.1.2, and it should be possible to get the old behaviour back using the newly introduced --waitip switch: http://roy.marples.name/projects/dhcpcd/changeset/1ad3d0c85b6b681ea59b05686c13e89a4c227f63/ Therefore I assume that adding dhcpcd_eth0="--waitip" to my /etc/conf.d/net should get things back to normal. I have several points where things could be improved: 1. elog about this change, so admins can avoid trouble from ever happening 2. Add a suitable example to /usr/share/doc/openrc-*/net.example 3. Perhaps make waitip the default 4. Perhaps introduce a generic DHCP option to control such forking 5. Find a way for scripts depending on net to wait for an actual IP
All, my thinking about this is to handle it the same way we handle the zeroconf option. In other words, what do you think about having a waitip local use flag which would be on by default, and if it was on, would add something like this to /etc/dhcpcd.conf: # do not fork to the background until an ip address is obtained waitip and, if the flag was off, it would generate an ewarn that there could be issues.
(In reply to comment #1) > In other words, what do you think ... I have mixed feelings about this: + use flags are a thing Gentoo admins should be at home with + flag would make the thing visible at emerge time + flag could be set to enabled by default, minimizing switchover headaches + would be consistent with zeroconf support + avoids at least some unnecessary elog messages - a use flag only affecting a simple runtime config file feels a bit overkill - people would needlessly rebuild dhcpcd where a simple config edit would do - people might fail to realize that they can control this per device - adds to the number of places where dhcpcd is configured, like /etc/dhcpcd.conf and /etc/conf.d/net - might one day lead to a huge abundance of use flags like this If this were just any application package, I'd vote for elog and config editing by admins only. As this is a rather essential part of the system, though, and as dhcpcd builds fairly quickly, I believe that escpecially the increased visibility of the change would warrant the introduction of a USE flag. Therefore a vote in favor from me.
All, In my initial testing for this, I have discovered that waitip and zeroconf are mutually exclusive. If waitip is on, dhcpcd will exit with an unsuccessful status if it cannot get an actual address from a dhcp server. Zeroconf support allows dhcpcd to continue to run and update the interface and routing table once a server becomes available. So, which setting should we have as the default?
(In reply to comment #3) > In my initial testing for this, I have discovered that waitip and > zeroconf are mutually exclusive. They should not be. > If waitip is on, dhcpcd will exit with > an unsuccessful status if it cannot get an actual address from a dhcp > server. It should then run zeroconf (if enabled) and wait for a futher 8 seconds or so. Basically, if zerconf is enabled then the exist code is nearly always 0, even with waitip. The only instance where it is not is when there is a Reverse ARP proxy present.
Roy, here is the test I ran: 1) comment out everything in /etc/conf.d/network. 2) add waitip to /etc/dhcpcd.conf. 3) put the network service in the boot run level. 4) put the dhcpcd service in the default run level. 5) halt the computer and disconnect the ethernet cable. 6) power the computer back on. dhcpcd started, timed out, waited another 8 seconds, then failed. If, on the other hand, I remove waitip from dhcpcd.conf, zeroconf seems to work. The rc.log and dhcpcd.conf for the failure are attached.
Created attachment 208016 [details] rc.log In this reboot, dhcpcd is in the default runlevel with no ethernet cable connected.
Created attachment 208017 [details] dhcpcd.conf Here is the dhcpcd.conf. To get my other scenario, just comment out waitip and reboot again with the ethernet cable disconnected.
Let me re-clarify slightly. When waitip is used, dhcpcd will always wait for an IP assignment. If none is made then dhcpcd will exit with an error. IPv4LL and DHCP requests will not be made if there is no carrier. IPv4LL (zeroconf) being enabled or disabled does not affect this behaviour. Instead of speculation as to if and where a dhcpcd bug exists, I suggest the OP puts forward the expected requirements.
(In reply to comment #8) > Instead of speculation as to if and where a dhcpcd bug exists, > I suggest the OP puts forward the expected requirements. My personal requirements are quite simple: Things that used to work before should continue to work, either because default behavious doesn't change, or because admins are notified of such a change in a suitable way. As I'm dealing with only a fixed network here, I don't care about zeroconf. I didn't bother to disable it as there was no need, but I'm not using it. In general, I assume zeroconf is likely a thing for mobile users using different networks, some of them without dns server, and where network connection is non-essential and thus backgrounding sounds reasonable as well. So I think the combination of zeroconf and waitip is a bit of a corner case where I have no intuitive expectation as to what should happen. I guess you guys are more likely to come up with a good suggestion as to whether that combination of waitip and zeroconf is allowed and what the resulting behaviour should be. Maybe that's a different bug though -- if it is a bug at all -- because my original post was about the introduced backgrounding breaking current fixed network configs, without any mention of zeroconf.
Created attachment 208198 [details, diff] Enable waitip for single interface This retains compat with prior dhcpcd versions.
Since upstream made the requested behavior the default when dhcpcd is running on only one interface, this maintains compatibility with older versions without the addition of the waitip use flag.
