also see http://marc.theaimsgroup.com/?l=linux-ppp&m=107498594022952&w=2
Created attachment 35514 [details, diff] control_c.patch
Created attachment 35515 [details] ppp-2.4.2-r2.ebuild
Obviously a duplicate of #51889. We just proposed the same patch there... :-) I added agriffis and lanius to CC: Hope that the don't get annoyed but all these mails. Axel P.S.: Maybe the owner of this bug (Thomas) should increase priority.
ack
*** Bug 51889 has been marked as a duplicate of this bug. ***
Fixed in ppp-2.4.2-r3.ebuild
Thanks for adding the <<control_c.patch>> Terminating <<pppd>> with signal 15 (TERM) now works as expected. But... because shutting down the ppp-connection may take some time (about 3 seconds on my gentoo box, while a PPTP/VPN- connection to a watchguard firebox is active), I do not think that sending subsequent signals to the ppp-process is a good idea. As I have already proposed <<net.ppp0 stop>> should just wait a little longer, i. e. <<kill ${PID}>> in the while loop [ ${COUNT} -lt 10 ] should be subsituted by <<ewarn "Waiting for ${IFACE} to go down...">> or something similar. This modification results to the following output, when shutting down the ppp-connection (and take about 3 seconds) * Bringing ppp0 down... * Waiting for ppp0 to go down... * Waiting for ppp0 to go down... [ ok ] The unmodified version results to the following output (and takes the full 10 seconds) * Bringing ppp0 down... * Error stopping pppd [ !! ] [ ok ] Also with the unmodified version the final result is 1. the <<<ppp link>> is down and 2. the <<net.ppp0 service>> is stopped ... but with the cost of some extra seconds and an unneccessary error message. If I'm the only one that is affected, forget about this comment. If not, then "-r3" should be updated by changing the corresponding line in <<files/2.4.2/net.ppp0>> Greets Axel (XL)
