DHCP6c SIGTERM, SIGKILL
I have found that when issuing a SIGTERM to dhcp6c that it immediately deletes the pid file, however, if the WAN interface is down then it will continue to send release signals for at least thirty seconds. The issue here is that the call to kill the process checks to see if the process is still alive before issuing a final sigkill, as the pid has been deleted that sigkill does not get sent as dhcp6c continues on.
I have issued an UPSTREAM PR to correct this along with some additions.
#3 Updated by → luckman212 over 3 years ago
Thank you very much. I am testing these now. I got the binaries scp'd onto the test box. I moved the stock binaries to /root/orig/ then ran chmod 555 dhcp6* on the replacements, since the old binaries were set r-xr-xr-x. After that, I applied the 417f208188be97c0fb9edf800d8e9aa2fe61d174 patch and rebooted. Everything is up and running as of now, also updated to latest snap 2.4.0.b.20170202.1158
I had the stock dhcp6c fail on me earlier tonight after a brief 7 minute WAN2 outage. WAN2 came back up but DHCP6 Gateway status was "Unknown" on Dashboard as well as Status > Gateways. I checked from console and there was only 1 dhcp6c process running (which was an improvement over the 2.3.2_p1 behavior where I would often wind up with 3 copies of the daemon!) But still, something was amiss.
So if this fixes things, it would be very timely. Will report back. cheers
#5 Updated by Martin Wasley over 3 years ago
Yes, they are both 'hopefully' put to sleep with the changes done in the script patch I sent you and with dhcp6c changes. My testers are just going through a few final revisions - changed the logging a bit and introduced another new signal, that's for future use with the lease release button that's appeared.
I'll send you the latest revision to play with, hopefully I can issue a PR Monday or Tuesday on this if none of the testers come back with any negatives.
New stuff will be in your inbox shortly.