Hi, I am seeing this sometimes after I boot my system (/var/log/messages) Jun 6 16:28:24 mchandras-linux dhcpcd[1668]: version 5.99.6 starting Jun 6 16:28:25 mchandras-linux dhcpcd[1668]: no interfaces have a carrier Jun 6 16:28:25 mchandras-linux dhcpcd[1668]: forked to background, child pid 1691 Jun 6 16:28:25 mchandras-linux dhcpcd[1691]: eth0: waiting for carrier Jun 6 16:28:27 mchandras-linux dhcpcd[1691]: eth0: carrier acquired Jun 6 16:28:27 mchandras-linux dhcpcd[1691]: eth0: sending IPv6 Router Solicitation Jun 6 16:28:27 mchandras-linux dhcpcd[1691]: eth0: sendmsg: Cannot assign requested address Jun 6 16:28:27 mchandras-linux dhcpcd[1691]: eth0: rebinding lease of 192.168.154.67 Jun 6 16:28:27 mchandras-linux dhcpcd[1691]: eth0: acknowledged 192.168.0.2 from 192.168.0.254 Jun 6 16:28:27 mchandras-linux dhcpcd[1691]: eth0: checking for 192.168.0.2 Jun 6 16:28:32 mchandras-linux dhcpcd[1691]: eth0: leased 192.168.0.2 for 3600 seconds Jun 6 16:29:44 mchandras-linux dhcpcd[1691]: received SIGTERM, stopping Jun 6 16:29:44 mchandras-linux dhcpcd[1691]: eth0: removing interface Jun 6 16:29:44 mchandras-linux dhcpcd[1691]: exited So what happens here is that the dhcpcd init script starts, gets an IP and then for some reasons it gets a SIGTERM signals and exists rendering the future DHCP operations useless. I haven't tested any previous dhcpcd versions on this system as I used to had a static IP in the past. I must say that does not happen all the time. This is my dhcpcd.conf file mchandras # grep -v "^#\|^$" /etc/dhcpcd.conf hostname duid option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes option ntp_servers require dhcp_server_identifier nohook lookup-hostname waitip
So something sent dhcpcd a SIGTERM. Sadly dhcpcd doesn't know which PID sent it. I suppose I could code this into a future version. I'll go out on a limb and suggest that the Gentoo network scripts are doing this. I would suggest adding dhcpcd to a runlevel by itself and let it work in peace.
Roy I run dhcpcd on the boot runlevel. I have not net.eth* on any runlevel apart from net.lo which is also on the boot runlevel. Should I remove net.lo as well?
Hmmmm no, don't remove net.lo You posted a log with dhcpcd-5.99.6. Does 5.99.7 behave the same way? Do you see the same problem with dhcpcd-5.5.x or dhcpcd-5.6.x?
(In reply to Roy Marples from comment #3) > Hmmmm no, don't remove net.lo > > You posted a log with dhcpcd-5.99.6. Does 5.99.7 behave the same way? Do you > see the same problem with dhcpcd-5.5.x or dhcpcd-5.6.x? I have 5.99.7 installed, rebooted the box, yet the log says that 5.99.6 is starting. Not sure why... I just downgraded to 5.6.8. I will do a couple of reboots to see if I am able to reproduce it.
I am running 5.6.8 since this morning on two separate boxes and everything seems to work fine after multiple reboots. It could be a problem with 5.99.7 or it could have been a temporary problem and caused SIGTERM to be delivered. I am not going to do more tests since these are production systems so feel free to close this bug if you want to.
The next dhcpcd release will log the PID where the signal came from, which may or may not assist in debugging this.
Thanks. Once the new release is out I will update again
Hi Markos, Is this still an issue with 6.0.2? Thanks, William
Ok, I'm closing this as worksforme. Markos, if this comes up again with 6.0.5, feel free to reopen.
