log rotation
Mark Foster
earlier today. I went to restart it and was greeted by this...
Filesize limit exceeded (core dumped)
So, realizing the logfile /var/log/stunnel.log was over 2gb, I quickly renamed
it and all is well... sort of.
With some 20+ other instances I need a painless way to do log rotation so this
doesn't happen again. I began a /etc/logrotate.d/stunnel to do that, but it is
unclear what signal I can send to stunnel to have it re-open it's logfile
I've tried USR1 and HUP but both kill the process completely.
Any suggestions? Here's my logrotate config for reference.
compress
/var/log/stunnel.log {
daily
rotate 5
missingok
postrotate
/bin/kill -USR1 `cat /tmp/stunnel.pid` <---this doesn't work
endscript
}
--
Some days it's just not worth chewing through the restraints...
Mark Foster <ma...@foster.cc> http://mark.foster.cc/
Brian Hatch
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> With some 20+ other instances I need a painless way to do log rotation so this
> doesn't happen again. I began a /etc/logrotate.d/stunnel to do that, but it is
> unclear what signal I can send to stunnel to have it re-open it's logfile
> I've tried USR1 and HUP but both kill the process completely.
None currently supported. Patches encouraged.
A signal to re-reading the config file has been suggested
on many occasions, I took a quick stab at it once but
never had time to work on it enough (needs to re-create
CTX and reload certs, etc etc etc.)
A signal to re-open the log file should be pretty
trivial to do, however.
--
Brian Hatch "Politics" etymology:
Systems and Poli -- 'many'
Security Engineer tics -- 'bloodsucking
http://www.ifokr.org/bri/ creature'
Every message PGP signed
--8Y8a5CJOPM/zJV44
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/qslsidaA3abfMooRAtxiAJ9IRQmNF54iu71BKR2AErnLXsiVhQCggchA
a/aDLnnf4tShXm1vHVzJtJM=
=Xuqc
-----END PGP SIGNATURE-----
--8Y8a5CJOPM/zJV44--
Eben
>
>A signal to re-open the log file should be pretty
>trivial to do, however.
You could just copy the log, then zero the original out:
#!/bin/ksh
# Script to rotate logs.
# Run from cron; 59 23 * * * /export/home/epratt/scripts/logrotate.ksh
# Eben Pratt, June 2001
LST='/bin/ls'
GRP='/bin/egrep'
CMP='/bin/compress'
DTE=`date +%Y%m%d`
TAI='/usr/local/bin/tai64nlocal'
DTL="dnscache|ipf|pop3d|send|stunnel-pop3s|tinydns"
for DIR in `${LST} -d /var/log/* | ${GRP} ${DTL}`
do
/bin/find ${DIR}/*.Z -mtime +90 -exec rm {} \;
for LIN in `${LST} ${DIR} | ${GRP} @`
do
/bin/cat ${DIR}/${LIN} | ${TAI} >> ${DIR}/old
/bin/rm ${DIR}/${LIN}
done
/bin/cat ${DIR}/current | ${TAI} >> ${DIR}/old
/bin/cat /dev/null > ${DIR}/current
/bin/cat ${DIR}/old | ${CMP} -cf - > ${DIR}/old.${DTE}.Z
/bin/rm ${DIR}/old
done
Mark Foster
Here's a patch to enable the reopening of the output logfile on SIGHUP.
Anyone using this patch should be wary of the suid permissions of the stunnel process vs. the permissions of the output directory.
diff -cr stunnel-4.04.orig/src/stunnel.c stunnel-4.04/src/stunnel.c
*** stunnel-4.04.orig/src/stunnel.c Sun Jan 12 07:46:55 2003
--- stunnel-4.04/src/stunnel.c Thu Nov 6 15:39:30 2003
***************
*** 567,575 ****
#ifndef USE_WIN32
static void signal_handler(int sig) { /* signal handler */
! log(sig==SIGTERM ? LOG_NOTICE : LOG_ERR,
"Received signal %d; terminating", sig);
! exit(3);
}
#endif /* !defined USE_WIN32 */
--- 567,583 ----
#ifndef USE_WIN32
static void signal_handler(int sig) { /* signal handler */
! if (sig == SIGHUP) {
! log(LOG_NOTICE, "SIGHUP received: reopening logfile");
! log_close();
! log_open();
! log(LOG_NOTICE, "%s", stunnel_info());
! } else {
! log(sig==SIGTERM ? LOG_NOTICE : LOG_ERR,
"Received signal %d; terminating", sig);
! exit(3);
! }
!
Brian Hatch
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> I run all of my stunnel's under daemontools, which handles log
> rotation automatically.
>=20
> http://cr.yp.to/daemontools.html
But costs you, since you don't get the advantage of
session-id reuse. (Unless you've compiled it with
distcache. I haven't played with it yet, but it's
a great idea.)
--
Brian Hatch If Microsoft Windows is
Systems and the solution, can we
Security Engineer have the problem back
http://www.ifokr.org/bri/ instead?
Every message PGP signed
--oIUK9dbftDTPhBGO
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/r/wRidaA3abfMooRAneBAKCKdLtqmw8lesR/Xm1WJnu3+Ly4MgCfflme
gC/aQoCU4JmrsAwUlA+lEyk=
=KNL6
-----END PGP SIGNATURE-----
--oIUK9dbftDTPhBGO--
Michal Trojnara
Hash: SHA1
Mark Foster wrote:
> Here's a patch to enable the reopening of the output logfile on SIGHUP.
> Anyone using this patch should be wary of the suid permissions of the
> stunnel process vs. the permissions of the output directory.
It's not so trivial (besides the permission problem):
- with threads support enabled the patch will fail when some thread will log
something in between log_close() and log_open() calls,
- with fork (threads support disabled) the patch will fail because it only
affects the main process -- all the other processes will continue to log to
the old file as long as they're alive.
What about simple logging with syslog?
Best regards,
Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/sIuC/NU+nXTHMtERAg77AKCj4rf24ysR0dW9kRXpnlzuxzJsuACfe8HW
9yvhzNxZ6j92KDldB+Np5sA=
=/gtp
-----END PGP SIGNATURE-----
Jeff Woods
Content-Type: text/plain;
charset="iso-8859-2"
Michal Trojnara <Michal....@mirt.net> replied:
> Mark Foster wrote:
>> Here's a patch to enable the reopening of the output logfile on
>> SIGHUP. Anyone using this patch should be wary of the suid
>> permissions of the stunnel process vs. the permissions of the output
>> directory.
>
> It's not so trivial (besides the permission problem):
> - with threads support enabled the patch will fail when some thread
> will log something in between log_close() and log_open() calls,
Is there some reason it shouldn't lock the logging semaphore around the
close/open?
> - with fork (threads support disabled) the patch will fail because
> it only affects the main process -- all the other processes will
> continue to log to the old file as long as they're alive.
That doesn't seem to be a problem if you rename the old logfile. It will
only get messages that continue existing connections. (It sounds almost
like a desirable feature to me.) Just document that the old logfile will
not quiesce (in fork mode) until the last connection ends.
> What about simple logging with syslog?
That's good for folks using syslog... Assuming they're on systems that
support it. Of course, not all systems support signals either.
--
Jeff Woods
je...@qss.com
------_=_NextPart_001_01C3A888.E90A97B0--