Re: hostname.pppoe0, !/bin/sh when reconnecting
I am in a similar situation (pppoe sessions restarts, although my IP addresses do not change), and I needed to re-add the default IPv6 route after completion of IPv6CP. Note that there are several layers involved (link, IPv4, IPv6), I would guess that for pppoe "link is up" would mean LCP succeeded, which is before you get a new IP. For this reason I put together a small ad-hoc tool that monitors the addition of a new route, which occurs just after IPv6CP succeeds. See https://marc.info/?l=openbsd-misc=158834859429490=2 You could probably modify it to do what you need, using the monitor option of route(8) to guess what event you want to trigger the execution of your script. In fact it should be simpler. If you manage to use ifstated(8) reliably, please let me know. On Wed, Jun 17, 2020 at 01:08:30PM +, Lévai, Dániel wrote: > Hi misc@! > > I'm trying to run a script whenever I get a new IP address from my ISP over > pppoe0. They disconnect me occasionally and the router reconnects then, eg.: > /bsd: pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated > /bsd: pppoe0: received unexpected PADO > last message repeated 2 times > > I have this as the last line in /etc/hostname.pppoe0: > !/bin/sh /etc/hostname.pppoe0.script pppoe0 0.0.0.1 > > It doesn't seem to be executed when this happens, only when I reboot the > router. Is the culprit here something along the lines of not (re)configuring > the interface with ifconfig up/down (in which case the script would run), > instead only getting disconnected and reconnecting? > > > Daniel >
pppoe LCP keepalive timeouts and inet6 default route
My DSL connection, using a modem in "bridge" mode and pppoe(4), suffers from disconnections every few (5 or so) days. The following message is printed in the syslog: pppoe0: LCP keepalive timeout which indicates that several Echo-Requests were not followed by replies, so the kernel considers the connection to be dead and tries to reestablish the PPP session. Perhaps this could be fixed by the ISP, or perhaps it comes from the modem, and perhaps it could be fixed by increasing either MAXALIVECNT or the sec parameter in the relevant timeout_add_sec(9) call in src/sys/net/if_spppsubr.c (currently these are hard-coded but it would be nice to make these parameters accessible through ifconfig(8): see the "bugs" section in sppp(4)). The disconnection itself is not the problem that I want to discuss right now. sppp(4) manages to reconnect (sometimes it takes a few minutes, presumably because the other end is not happy that the previous connection was not properly terminated), and so as long as the reconnections are not too frequent it is not too big of an issue. My main problem is that the default IPv6 route, configured by adding !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 to /etc/hostname.pppoe0 as suggested by the manual, does not survive the reconnection (to be precise, all IPv6 addresses are purged when the new IPv6CP dance succeeds, and so the routes are purged as well). This is surprising because the default IPv4 route does survive the reconnection (route -n monitor tells me that some magic happens with the "special" addresses 0.0.0.0 and 0.0.0.1). Of course running the above route command reinstates the default IPv6 route, but this has to be done manually. Is this problem known? Is it the case for all sppp(4) connections (with IPv6 enabled of course), or even for all similar point-to-point interfaces? If your connection is reliable, you can simply unplug the phone line for about 30 seconds to try to reproduce this issue. A detail that can make my case somewhat particular: for some reason none of the DHCPv6 clients in ports worked for me (even if I temporarily disable the firewall, my "solicit" remain unanswered) but since my ISP informed me of my prefix, I could simply configure the "local" interface of the router with a static IPv6 address, and similarly for rad(8). Fortunately my ISP is routing the IPv6 packets on my line even without prefix delegation. I considered the following possible solutions. 1) The kernel could have a way of remembering the default IPv6 route that was added, like for IPv4. I don't know what kind of complication to the routing code that would entail. 2) I considered using ifstated(8) to add the default route anytime pppoe0 comes up, but this does not seem to be the right event: if I understand correctly, the interface is marked as "up" when the PPP dance succeeds, before any one of the NCP dances succeeds. One could have a little nap between the "up" event and the addition of the default IPv6 route, but that does not seem right. One could add more interface events to ifstated(8), but perhaps that is too complicated for this particular tool? 3) As a temporary measure, I wrote a small program (with a lot of copy-paste from the source of ifstated(8) and route(8), see attachment) that waits for the addition of new route with destination fe80::%pppoe0, and subsequently adds the sought default route. It worked at least once, so I am hopeful that it will work always. I have no doubt that it could be improved (for starters, the name of the interface could be passed as argument). PS: although the route(4) man page was really useful to understand how to talk to the kernel, it does not give all the details to do so (e.g. alignment on "long" for the sockaddrs, the way scope ids are embedded in link-local addresses, and which fields in the sockaddrs are actually used by the kernel). That is not really preventing anyone to interact with the kernel because there are many examples of code in base (sys/net/rtsock.c, sbin/route/*.c, ...), but I thought I would point it out just in case the goal is to have the route(4) man page be self-contained. pppoeroute.c.gz Description: Binary data
Re: non-interactive sh and SIGTERM
Thanks for the explanation, it makes sense to use pgids for that purpose. In the case in which I am interested (vimtex plugin failing to kill latexmk, which works on another machine running debian linux) I guessed that the plugin sent a SIGTERM signal only to the 'sh -c' process, which would work with bash because bash somehow terminates the subprocess immediately. But I guessed wrong: vimtex uses vim's job_stop, which according to vim's help should send the signal to the process group, with the explicit intent of terminating 'sh -c' commands. So this issue comes from either vim or vimtex. On Sun, Nov 25, 2018 at 09:04:22PM -0800, Philip Guenther wrote: > On Fri, Nov 23, 2018 at 1:51 PM Olivier Taïbi wrote: > > > Sorry about the wrong report, I just tested again and I can see the same > > behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after > > launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to > > the sleep process. > > > > Hmm, why should it? If you wanted to kill whatever processes where started > from that invocation, shouldn't you send SIGTERM to the process group? > > > > > Philip, what was your test? > > > > : morgaine; sh -c 'while :; do :; done' & > [3] 16632 > : morgaine; kill 16632 > [3] - Terminated sh -c "while :; do :; done" > : morgaine; > : morgaine; sh -c 'while :; do sleep 1; done' & > [3] 59539 > : morgaine; kill 59539 > : morgaine; > [3] - Terminated sh -c "while :; do sleep 1; done" > : morgaine; > > sh itself doesn't ignore SIGTERM, but rather exits after receiving it. > > > Philip Guenther
Re: non-interactive sh and SIGTERM
Sorry about the wrong report, I just tested again and I can see the same behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to the sleep process. Philip, what was your test? Thanks On Fri, Nov 23, 2018 at 09:50:29AM +0100, Olivier Taïbi wrote: > After some testing, this issue does not seem to be directly caused by > ksh. Compiling ksh from a year ago, I get the same behaviour: SIGTERM is > not passed on to child. I'm not sure what to try next. Bisecting > /usr/src? > > On Fri, Nov 23, 2018 at 08:55:16AM +0100, Olivier Taïbi wrote: > > On Thu, Nov 22, 2018 at 05:14:38PM -0800, Philip Guenther wrote: > > > On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi wrote: > > > > > > > It seems that non-interactive sh(1) (i.e. sh -c command or sh file) > > > > ignores the TERM signal. I'm surprised, is this the intended behaviour? > > > > The man page says that interactive shells will ignore SIGTERM, but does > > > > not mention the non-interactive case. > > > > > > > > > > In my quick test it doesn't ignore SIGTERM, so you'll need to provide > > > additional information for us to help you. > > > > Oops, I did not notice that sh ignores SIGTERM on my -current > > installation but not on 6.4 (different machine though). The minimal test > > is: > > sh -c 'sleep 1000' > > then kill this sh process. Nothing happens, but killing the sleep > > process terminates it. > > > > In fact it is not completely true that sh ignores SIGTERM, but it seems > > that it is waiting for the current running command to terminate on its > > own, rather than forwarding the signal. That is, after running > > sh -c 'while [ -z "" ]; do sleep 10; echo test; done' > > and sending SIGTERM to sh, it will terminate (and print 'Terminated') > > after the sleep is complete. > > > > I did not imagine this was recent because I thought that this behaviour > > was the reason for this bug: > > https://github.com/lervag/vimtex/issues/1032 > > that I can reproduce. > > > > Thanks for your help. > > > > > > > > Philip Guenther
Re: non-interactive sh and SIGTERM
After some testing, this issue does not seem to be directly caused by ksh. Compiling ksh from a year ago, I get the same behaviour: SIGTERM is not passed on to child. I'm not sure what to try next. Bisecting /usr/src? On Fri, Nov 23, 2018 at 08:55:16AM +0100, Olivier Taïbi wrote: > On Thu, Nov 22, 2018 at 05:14:38PM -0800, Philip Guenther wrote: > > On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi wrote: > > > > > It seems that non-interactive sh(1) (i.e. sh -c command or sh file) > > > ignores the TERM signal. I'm surprised, is this the intended behaviour? > > > The man page says that interactive shells will ignore SIGTERM, but does > > > not mention the non-interactive case. > > > > > > > In my quick test it doesn't ignore SIGTERM, so you'll need to provide > > additional information for us to help you. > > Oops, I did not notice that sh ignores SIGTERM on my -current > installation but not on 6.4 (different machine though). The minimal test > is: > sh -c 'sleep 1000' > then kill this sh process. Nothing happens, but killing the sleep > process terminates it. > > In fact it is not completely true that sh ignores SIGTERM, but it seems > that it is waiting for the current running command to terminate on its > own, rather than forwarding the signal. That is, after running > sh -c 'while [ -z "" ]; do sleep 10; echo test; done' > and sending SIGTERM to sh, it will terminate (and print 'Terminated') > after the sleep is complete. > > I did not imagine this was recent because I thought that this behaviour > was the reason for this bug: > https://github.com/lervag/vimtex/issues/1032 > that I can reproduce. > > Thanks for your help. > > > > > Philip Guenther
Re: non-interactive sh and SIGTERM
On Thu, Nov 22, 2018 at 05:14:38PM -0800, Philip Guenther wrote: > On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi wrote: > > > It seems that non-interactive sh(1) (i.e. sh -c command or sh file) > > ignores the TERM signal. I'm surprised, is this the intended behaviour? > > The man page says that interactive shells will ignore SIGTERM, but does > > not mention the non-interactive case. > > > > In my quick test it doesn't ignore SIGTERM, so you'll need to provide > additional information for us to help you. Oops, I did not notice that sh ignores SIGTERM on my -current installation but not on 6.4 (different machine though). The minimal test is: sh -c 'sleep 1000' then kill this sh process. Nothing happens, but killing the sleep process terminates it. In fact it is not completely true that sh ignores SIGTERM, but it seems that it is waiting for the current running command to terminate on its own, rather than forwarding the signal. That is, after running sh -c 'while [ -z "" ]; do sleep 10; echo test; done' and sending SIGTERM to sh, it will terminate (and print 'Terminated') after the sleep is complete. I did not imagine this was recent because I thought that this behaviour was the reason for this bug: https://github.com/lervag/vimtex/issues/1032 that I can reproduce. Thanks for your help. > > Philip Guenther
non-interactive sh and SIGTERM
It seems that non-interactive sh(1) (i.e. sh -c command or sh file) ignores the TERM signal. I'm surprised, is this the intended behaviour? The man page says that interactive shells will ignore SIGTERM, but does not mention the non-interactive case.
