[stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?

Wed May 15 19:24:20 CEST 2019

On Wed, May 15, 2019 at 08:41:40AM +0000, Jochen Bern wrote:
> On 05/15/2019 12:22 AM, Florian Lohoff wrote:
> > On Tue, May 14, 2019 at 11:30:29AM -0700, Eric Eberhard wrote:
> >> That is not a bad idea.  I'd wrap it in a C program so I could check
> >> if the pppd is alive and not a zombie.
> > 
> > pppd is a pretty solid piece of software. Never seen it hang as a
> > zombie.
> 
> A zombie process is *terminated* and, basically, just a remaining entry
> in the kernel's process table. It's not hanging around because of
> something its own code did wrong, but because its parent process fails
> to "reap" its child (first and foremost, collect its exit code from the
> kernel). Killing the parent cleans up zombies because the zombies get
> re-parented to the init / systemd process (PID 1), which then does the
> reaping.

The point is - if pppd is a real zombie everything is fine. As then all
kernel resources have already been cleared away already - like interface
and routes. And that (from my understanding) is the real problem.
Starting a second pppd with the same static ip address for the peer.

And what i meant is that the pppd state machine is pretty solid and
clears away everything if the peer is detected dead for example
with the lcp echo request/reply.

Flo
-- 
Florian Lohoff                                                 f at zz.de
        UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20190515/1b89599a/attachment.sig>