Most O/S will either prevent renaming a file that is in use (or deleting it). Some will – but they will actually continue to write to the old file (and if that file was deleted then it writes to a file you can nexer see). Since I generally use AIX it is the second feature I see. We have systems with over 500 connections via stunnel – it never rests, and rolling the log file is not easy.

I can easily provide a code fix for stunnel that we use in out software. It allows daily logs, sized logs, etc. And it rolls properly. The downside is we open the log, write to it, and close it – each time – which is not efficient. Given modern computers I have come to not care. So the open routine either opens (append) a daily file or it looks up the file and gets the size and decides to move it (or not). The second is not perfect … if three other processes have it open at the moment they will finish writing to that log. Who cares? As long as the logging is always opening and closing the “bleed over” is minimized.

If people want me to do this, I will – if they can tell me the log routines it would speed me some, preventing from having to search for them.

We like and prefer the daily logs – it is clean as you get one per day. As long as one day is never too huge it is great and we have daemons that remove logs over xx number of days (although I could add a simple parameter for that as well and simply kill those files).

This is an annoying problem – especially for multi-O/S software – but one I am good at.

Eric

From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Daniel Trickett Sent: Wednesday, September 12, 2018 11:16 AM To: Tom Hood tom.w.hood@gmail.com Cc: stunnel-users@stunnel.org Subject: Re: [stunnel-users] stunnel log rolling

Hi Tom,

Is what you refer to? I think the open and re-open only happen when the service is stopped and restarted. It hasn’t rolled over like Apache in my short experience.

log = append | overwrite

log file handling

This option allows you to choose whether the log file (specified with the output option) is appended or overwritten when opened or re-opened.

default: append

Best regards,

Dan

Daniel Trickett

Head of Database Services | MBS Business Technology

BX-TCS-O Oracle ERP

Business Services of Merck KGaA, Darmstadt, Germany

Planned Absence –

MilliporeSigma

A business of Merck KGaA, Darmstadt, Germany

EMD Millipore Corporation | 80 Ashby Road | Bedford, MA 01730 | USA

office 781-533-3017 |cell 978-761-3506 |email mailto:daniel.trickett@emdmillipore.com daniel.trickett@emdmillipore.com

From: Tom Hood <tom.w.hood@gmail.com mailto:tom.w.hood@gmail.com > Sent: Wednesday, September 12, 2018 1:10 PM To: Daniel Trickett <daniel.trickett@emdmillipore.com mailto:daniel.trickett@emdmillipore.com > Cc: stunnel-users@stunnel.org mailto:stunnel-users@stunnel.org Subject: Re: [stunnel-users] stunnel log rolling

Hi Daniel,

The trick is how to roll the logs without an interruption of service (i.e. without a stunnel restart). I believe stunnel claims to support this, but I think the feature might be broken in 5.49

Thanks,

-- Tom

On Wed, Sep 12, 2018 at 5:43 AM Daniel Trickett <daniel.trickett@emdmillipore.com mailto:daniel.trickett@emdmillipore.com > wrote:

Tom,

Kill the stunnel process. Then mv the log. This will allow stunnel to right to a new log file.

Best regards,

Dan

Daniel Trickett

Head of Database Services | MBS Business Technology

BX-TCS-O Oracle ERP

Business Services of Merck KGaA, Darmstadt, Germany

Planned Absence –

MilliporeSigma

A business of Merck KGaA, Darmstadt, Germany

EMD Millipore Corporation | 80 Ashby Road | Bedford, MA 01730 | USA

office 781-533-3017 |cell 978-761-3506 |email mailto:daniel.trickett@emdmillipore.com daniel.trickett@emdmillipore.com

From: stunnel-users <stunnel-users-bounces@stunnel.org mailto:stunnel-users-bounces@stunnel.org > On Behalf Of Tom Hood Sent: Tuesday, September 11, 2018 5:02 PM To: stunnel-users@stunnel.org mailto:stunnel-users@stunnel.org Subject: [stunnel-users] stunnel log rolling

Hi,

I'm new to stunnel and it isn't clear to me how the log rolling feature works.

I built stunnel 5.49 with gcc 4.2.0 on Solaris 10. I'm running it on Solaris 11.3 SPARC. Using openssl 1.0.2p

The config file has disabled syslog and is logging to stunnel.log.

Command line is: stunnel stunnel.conf

where stunnel.conf contains the following:

syslog = no

output = stunnel.log

debug = 7

[service-exterior]

client = no

options = NO_SSLv2

options = NO_SSLv3

options = NO_TLSv1

options = NO_TLSv1.1

options = -NO_TLSv1.2

cert = /path/to/stunnel.pem

curve = zzz

accept = testhost:32100

connect = 127.0.0.1:32200 http://127.0.0.1:32200

[service-interior]

client = yes

options = NO_SSLv2

options = NO_SSLv3

accept = 127.0.0.1:32200 http://127.0.0.1:32200

connect = 127.0.0.1:32100 http://127.0.0.1:32100

sslVersion = TLSv1

ciphers = zzz

TIMEOUTconnect = 60

The log rollowing steps I tried that don't work are:

mv stunnel.log stunnel.log.1

kill -USR1 <stunnelpid>

The log message "LOG7[main]: Processing SIGNAL_REOPEN_LOG" shows up in stunnel.log.1. However, new client connections to host:32100 do not trigger creation of a new stunnel.log file. In fact, logging stops to stunnel.log.1 as soon as the USR1 is processed. The new client connections work as before, but there isn't any logging.

I restarted stunnel and tried the test again with these steps:

mv stunnel.log stunnel.log.1

touch stunnel.log

kill -USR1 <stunnelpid>

That also doesn't work.

Please let me know the correct sequence of steps to roll the stunnel.log

Thank you,

-- Tom

This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.

Click http://www.emdgroup.com/emd/imprint/mail_disclaimer.html to access the German, French, Spanish and Portuguese versions of this disclaimer.

This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.

Click http://www.emdgroup.com/emd/imprint/mail_disclaimer.html to access the German, French, Spanish and Portuguese versions of this disclaimer.