Also a good idea. That would be found in the log ASAP certainly with a high debug level. Might fill the filesystem for the log if that is so :) Does FreeBSD support kill -9 (or is it 11?) that forces a core dump? If so, when you kill it and leave a core file, you can use the debugger on that core file and see what it is doing. Look at the stack trace. You may need several to catch the problem. If it is simply in a read() type state then the other machine is streaming you. If it is loop around you should see it in a different place in each core file (the odds of hitting the same line of code when kill it every time are not good). I do not know what debuggers you have (gdb?) but that is another trick.

Eric

From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Vincent Deschenes Sent: Wednesday, October 17, 2018 11:05 AM To: Murrey, Brian J. Brian.Murrey@trimedx.com; stunnel-users@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@stunnel.org mailto:stunnel-users-bounces@stunnel.org > On Behalf Of Murrey, Brian J. Sent: Wednesday, 17 October 2018 1:57 PM To: stunnel-users@stunnel.org mailto:stunnel-users@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.