[stunnel-users] CPU 100%

[Eric Eberhard]

One other suggestion - run it in inetd mode.  This is MUCH simpler, stunnel
will not have to do as much forking and managing and so forth.  The O/S will
do all that.  I know - it is a little less efficient.  However, I have found
on modern Centos and AIX computers that even with very high volumes it makes
no measurable difference.  If nothing else, it is another debugging
technique.  Especially if the runaway process is the parent process .
because that does not exist under inetd mode.

 

Eric

 

From: stunnel-users [mailto:stunnel-users-bounces at stunnel.org] On Behalf Of
Murrey, Brian J.
Sent: Wednesday, October 17, 2018 11:09 AM
To: stunnel-users at stunnel.org
Subject: Re: [stunnel-users] CPU 100%

 

We have one service, connecting stunnel to another application. Relevant
configuration:

 

[vpn]

client = no

accept = 172.17.102.122:443

exec = /usr/sbin/ppp

execargs = ppp -direct vpn

pty = yes

 

Brian

 

 

From: Vincent Deschenes <vdeschenes at stelvio.com
<mailto:vdeschenes at stelvio.com> > 
Sent: Wednesday, October 17, 2018 2:05 PM
To: Murrey, Brian J. <Brian.Murrey at trimedx.com
<mailto:Brian.Murrey at trimedx.com> >; stunnel-users at stunnel.org
<mailto:stunnel-users at stunnel.org> 
Subject: RE: [stunnel-users] CPU 100%

 

Just a silly idea, but is it possible you have a re-entrant configuration
for one service, one that connect back to itself creating a loop?

 

 

Vincent Deschenes Ing. PMP

 

 

From: stunnel-users <stunnel-users-bounces at stunnel.org
<mailto:stunnel-users-bounces at stunnel.org> > On Behalf Of Murrey, Brian J.
Sent: Wednesday, 17 October 2018 1:57 PM
To: stunnel-users at stunnel.org <mailto:stunnel-users at stunnel.org> 
Subject: [stunnel-users] CPU 100%

 

We are running stunnel 5.49 on FreeBSD 11.2 and we're running into a problem
once in a while. 

 

CPU pegs at 100% when we get an stunnel connection from one of our external
devices. 

This affects 100% of all cores and we can't even log in to console.

 

To mitigate this temporarily, we have a script running in the background to
watch when stunnel begins to spike and restarts the daemon.

 

It doesn't happen 100% of the time, and so far I have been unable to
distinguish what makes the connection do this to the CPU. 

 

Have any of you run in to this issue? 

 

 

Sincerely, 

 

 

Brian Murrey
System Engineer II, IT Infrastructure

 

  _____  

NOTICE: This message may contain privileged and confidential information
and/or protected health information intended solely for the use of the named
recipient and may be privileged or otherwise protected by law. If you are
not the intended recipient of this message, you should immediately notify
the sender and delete this message. Do not disseminate, reproduce, or review
this message or attachments if you are not the intended recipient. The
sender or others may have legal rights restricting the dissemination of the
information contained in this message and, as a result, remedies against you
in the event of the improper dissemination of confidential information,
trade secrets, personal information or privileged communications. This
message is the work of the sender and does not necessarily reflect the
position, views, or policies of TriMedx LLC or its affiliates.

WARNING: The integrity and security of this message cannot be guaranteed and
may contain or transmit a virus or other illicit code. Neither TriMedx LLC
or its affiliates accept liability for any damage attributable to viruses or
illicit code transmitted through this message or an attachment. 

  _____  

CAUTION: This email originated from outside of the organization. Do not open
links or attachments you were not expecting, even from known senders, and
use caution when responding. Please contact the Service Desk if in doubt
regarding the legitimacy of this email.

  _____  

NOTICE: This message may contain privileged and confidential information
and/or protected health information intended solely for the use of the named
recipient and may be privileged or otherwise protected by law. If you are
not the intended recipient of this message, you should immediately notify
the sender and delete this message. Do not disseminate, reproduce, or review
this message or attachments if you are not the intended recipient. The
sender or others may have legal rights restricting the dissemination of the
information contained in this message and, as a result, remedies against you
in the event of the improper dissemination of confidential information,
trade secrets, personal information or privileged communications. This
message is the work of the sender and does not necessarily reflect the
position, views, or policies of TriMedx LLC or its affiliates.

WARNING: The integrity and security of this message cannot be guaranteed and
may contain or transmit a virus or other illicit code. Neither TriMedx LLC
or its affiliates accept liability for any damage attributable to viruses or
illicit code transmitted through this message or an attachment. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20181017/b4e7fd3d/attachment.html>