dhcpcd-discuss

On Fri, Sep 4, 2020 at 7:10 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
>
> On 04/09/2020 15:00, Jouke Witteveen wrote:
> > On Thu, Aug 20, 2020 at 5:30 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
> >>
> >> On 16/08/2020 20:24, Roy Marples wrote:
> >>> On 16/08/2020 19:11, Roy Marples wrote:
> >>>> I am uncertain if igoring SIGTERM in the non master processes is a good thing
> >>>> or not. I've attached a patch which does this though - does it help at all?
> >
> > I'm pretty sure that ignoring SIGTERM in non-master processes is the
> > right thing to do. Service managers like systemd might spray SIGTERM
> > to all processes in a control group, and with this patch that does the
> > right thing.
>
> That was comitted a while ago and will be in the next release.
> https://roy.marples.name/cgit/dhcpcd.git/commit/?id=5a57bfe72ee7f13b8a3375e38251e3de6df75835

I noticed and did all my testing with a snapshot of today's git version :-).

> > However I am still seeing a weird bug which I think is related to the
> > one reported. The bug is seen with ifplugd. If I have a script that
> > simply starts dhcpcd when ifplugd detects a carrier. I know that this
> > is not necessary and dhcpcd can do this itself, but that is not the
> > point.
> >
> > With dhcpcd 8, ifplugd executes the script and reports "Program
> > executed successfully" and all is well.
> > With dhcpcd 9, ifplugd executes the script, but after the script
> > exits, it enters a <defunct> state (according to `ps`) and when
> > ifplugd is asked for its status (with `--info`), it outputs "Killing
> > child."?! In this state, ifplugd no longer executes the script on
> > changes in the carrier state.
> >
> > Do you know what change in dhpcd 9 could have caused this? What has
> > changed for a process that spawns dhcpcd?
>
> Sounds like the launcher process crashed somehow.
> Could you show the command line it launches dhcpcd with please?
> And maybe a core dump can be found to analyse?
>
> I was going to release a new dhcpcd version this weekend, but maybe we should
> try and fix this first?

I do think something could really be improved, but it may be too
difficult to fix it on a very short notice. Here is a complete
session, annotated with "----", that shows the issue:

# cat /tmp/ifplugd.action
#!/bin/bash

case "$2" in
  up)
    dhcpcd "$1";;
  down)
    dhcpcd -x "$1";;
esac
# /usr/bin/ifplugd -i eth0 -r /tmp/ifplugd.action -ns
ifplugd 0.28 initializing.
Using interface eth0/[...] with driver <e1000e> (version: 3.2.6-k)
Using detection mode: SIOCETHTOOL
Initialization complete, link beat detected.
Executing '/tmp/ifplugd.action eth0 up'.
client: dhcpcd-9.1.4 starting
client: DUID [...]
client: eth0: IAID [...]
client: eth0: soliciting an IPv6 router
client: eth0: Router Advertisement from [...]
client: eth0: rebinding lease of 192.168.[...]
client: eth0: leased 192.168.[...] for 86400 seconds
client: eth0: adding route to 192.168.[...]/24
client: eth0: adding default route via 192.168.[...]
client: forked to background, child pid [...]
^Z  ---- At this point the connection is fine and dhcpcd fully operational
[1]+  Stopped                 /usr/bin/ifplugd -i eth0 -r
/tmp/ifplugd.action -ns
# bg
[1]+ /usr/bin/ifplugd -i eth0 -r /tmp/ifplugd.action -ns &
# ifplugd -i eth0 -z
Killing child.  ---- This would show "running" with dhcpcd 8
# dhcpcd -x eth0  ---- [1]
sending signal TERM to pid [...]
waiting for pid [...] to exit
# Program executed successfully.  ---- output from the backgrounded ifplugd
# ifplugd -i eth0 -z  ---- [1]
SIGHUP: Running, link detected on eth0: yes

[1] By manually stopping dhcpcd, ifplugd realizes that the
ifplugd.action script has finished and the next time we ask it for its
status, it correctly outputs "running", although obviously we have now
lost dhcpcd. With dhcpcd 8, the first time we ask for the status of
dhcpcd it would immediately show "running".

I have left out dhcpcd debug output on purpose to keep this log short.
The debug output shows nothing out of the ordinary (at least to my
eyes).

Regards,
- Jouke