Re: Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?

Florian Lohoff <[email protected]> Wed, 15 May 2019 19:24:20 +0200

Newsgroups	gmane.network.stunnel.user
Organization	rfc822 - pure communication
Message-ID	<[email protected]>

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                                                 [email protected]
        UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

signature.asc (application/pgp-signature, 833 B)