[sslh] sslh-1.7a - problem with zombies

Bud Curry Bud at computereaseofmd.com
Tue Jul 13 17:56:14 CEST 2010


Unfortunately, the router firmware is based on BusyBox, so pstree is not
available.  However, in the output of ps, the command is shown as
[sslh], which I believe indicates that the parent is the sslh process.
And remember, when I kill the main sslh process, the zombies get killed
along with it.

I tried the mod that Yves' suggested
(http://rutschle.net/pipermail/sslh/2010-May/000010.html), but it didn't
make any difference.

Thanks for the feedback.

-----Original Message-----
From: Rich Rauenzahn [mailto:rich at shroop.net] 
Sent: Tuesday, July 06, 2010 12:48 PM
To: Bud Curry; 'Matthias Buecher / Germany'; sslh at rutschle.net
Subject: Re: [sslh] sslh-1.7a - problem with zombies



Realize that zombies are processes whose exit status hasn't been
collected yet -- usually through a wait() system call.  When you kill
the parent process, the zombies get inherited by init (pid=1) who
periodically does a wait().

It looks like sslh does setup signal handlers properly to deal with this
(See setup_signals() in the source -- SA_NOCLDWAIT cleans them up
automatically.)

What is the immediate parent process ID of your zombies?  That is your
culprit.  If you have pstree, try using that to see the lineage.

I just saw Yves' post -- I would definitely try that as well, although
my Linux system isn't seeing zombies. Perhaps it is a BSD specific
difference.

Rich

-----Original Message-----
From: sslh-bounces at rutschle.net [mailto:sslh-bounces at rutschle.net] On
Behalf Of Bud Curry
Sent: Tuesday, July 06, 2010 8:01 AM
To: Matthias Buecher / Germany; sslh at rutschle.net
Subject: Re: [sslh] sslh-1.7a - problem with zombies

Thanks for taking a look at this.

My primary uses are remote access from work (through a corporate
firewall) via SSH, and Outlook Web Access via SSL for synchronizing my
mobile phone.  I have been off work for the last couple of days, so I
haven't created any SSH connections.  So, the only clients to access it
would be a browser (Opera Mobile and IE8) and ActiveSync.  I'm still
getting zombies.  So, while I suppose these apps could be causing the
zombied connections, these are mainstream apps, so I would think the
problem would be more pervasive if that was the case. In any event, if
these clients are causing the zombies, there would be little I could do
to change their behavior.  So, any ideas on how to modify sslh to detect
and delete child processes that have become zombies?


-----Original Message-----
From: Matthias Buecher / Germany [mailto:maddes.b at arcor.de]
Sent: Monday, July 05, 2010 4:12 PM
To: sslh at rutschle.net
Subject: Re: [sslh] sslh-1.7a - problem with zombies

Did some tests today (OpenVPN 2.1.1, DropBear sshd v0.52), no zombies
here.
Could it be that these "zombies" are caused by zombie connections of the
applications you use?

Maddes


On 02.07.2010 23:58, Matthias Buecher / Germany wrote:
> I'm running sslh 1.7a on my Linksys WRT350Nv2 (Marvell Orion CPU,
> ARMel) with OpenWrt Backfire and never recognized any zombies.
> Unfortunately after 1 month of running I upgraded my router today, so 
> no connections yet, but will do some tests this week and keep an eye
it.
> 
> Maddes
> http://www.maddes.net/
> 
> 
> On 02.07.2010 22:05, Bud Curry wrote:
>> My goal is to run sslh on my WRT54GL running Tomato firmware (1.28). 
>> I'm a developer, but my Linux expertise is very limited. Despite 
>> that, I have managed to cross-compile the source for MIPSEL and got 
>> it loaded and running. The problem I'm having it is that, while it 
>> works, it seems to accumulate a lot of zombie child processes, and so

>> eventually stops accepting new requests. If I kill the main sslh 
>> process, these child processes die. I then can restart sslh and all
is well again for awhile.
>> I suppose I could create a cron job to restart sslh every so often, 
>> but there has to be a better way.
>>
>> Any thoughts on this?  Anyone else running this on a Linksys router 
>> with third-party firmware?
>>
>> Thanks in advance. 
>>
>> Bud
>>



_______________________________________________
sslh mailing list
sslh at rutschle.net
http://rutschle.net/cgi-bin/mailman/listinfo/sslh







More information about the sslh mailing list