dhcpcd-discuss

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

> 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?

Roy