dhcpcd-discuss

Re: Issues with suspend-to-ram (netctl)

Jouke Witteveen

Sat Sep 05 17:21:19 2020

On Sat, Sep 5, 2020 at 6:09 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
>
> On 04/09/2020 20:59, Jouke Witteveen wrote:
> > 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
>
> I can replicate this on Devuan, thanks for the example.
> My diagnosis is that ifplugd is crashing - the equivalent setup using netplug
> rather than ifplugd works fine.

It looks more like stalling to me, but indeed, ifplugd seems to be
doing something weird.

> The fix is to setup a sockpair, close stdout/stderr when doing the initial fork
> and then send stderr via the socketpair which the launcher process can then send
> to the real stderr.
>
> What ifplugd is doing with stderr to cause this, I really don't know.

The fact that you figured this out so quickly is pretty amazing to me.
I'd be interested to read how you did it.

> This is probably a cleaner way of doing things, but we have now lost all output
> from dhcpcd-run-hooks from the initial start which I sometimes use to debug
> with. I will work on that later, but now the master branch should be good for you.
>
> Can you test it please?

Tested and the issue is gone! Impressive.

Thanks,
- Jouke

Follow-Ups:
Re: Issues with suspend-to-ram (netctl)Roy Marples
References:
Issues with suspend-to-ram (netctl)Jouke Witteveen
Re: Issues with suspend-to-ram (netctl)Roy Marples
Re: Issues with suspend-to-ram (netctl)Neal P. Murphy
Re: Issues with suspend-to-ram (netctl)Jouke Witteveen
Re: Issues with suspend-to-ram (netctl)Roy Marples
Re: Issues with suspend-to-ram (netctl)Roy Marples
Re: Issues with suspend-to-ram (netctl)Roy Marples
Re: Issues with suspend-to-ram (netctl)Jouke Witteveen
Re: Issues with suspend-to-ram (netctl)Roy Marples
Re: Issues with suspend-to-ram (netctl)Jouke Witteveen
Re: Issues with suspend-to-ram (netctl)Roy Marples
Archive administrator: postmaster@marples.name