Greetings list;
2 redhat employees are list as the authors of logrotate in the manpage, so I just sent them a question because it isn't working as expected.
Both emails bounced in the time it takes my fetchmail script to go suck the next cycle. Effectively instantly and permanently.
So how does one go about asking for logrotate help for a non-redhat distribution?
I am not running fedora atm.
Thanks.
On Wed, Aug 04, 2010 at 11:35:59AM -0400, Gene Heskett wrote:
Greetings list;
2 redhat employees are list as the authors of logrotate in the manpage, so I just sent them a question because it isn't working as expected.
On my logrotate man page, the date at the bottom is 2 Nov 2002 -- not terribly surprising that those email addresses are no good anymore!
Both emails bounced in the time it takes my fetchmail script to go suck the next cycle. Effectively instantly and permanently.
So how does one go about asking for logrotate help for a non-redhat distribution?
Open a bug at that distros bugzilla instance (or equivalent)?
I am not running fedora atm.
Shame on you! :-)
John
On Wednesday, August 04, 2010 12:13:32 pm John W. Linville did opine:
On Wed, Aug 04, 2010 at 11:35:59AM -0400, Gene Heskett wrote:
Greetings list;
2 redhat employees are list as the authors of logrotate in the manpage, so I just sent them a question because it isn't working as expected.
On my logrotate man page, the date at the bottom is 2 Nov 2002 -- not terribly surprising that those email addresses are no good anymore!
That is what I get for assuming manpages are current. Bummer. :( [...]
I am not running fedora atm.
Shame on you! :-)
John
Maybe John, but for the most part, (please, no religious wars are intended) it Just Works(TM), particularly the video & audio. And pclos uses a forum, no bz. :( msg posted there now, under "logrotate won't". :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/04/2010 11:35 AM, Gene Heskett wrote:
Greetings list;
2 redhat employees are list as the authors of logrotate in the manpage, so I just sent them a question because it isn't working as expected.
Obvious question: are you sure that the issue is logrotate and not the application whose logs you are trying to rotate?
For most daemons, logrotate works by doing the following:
1) Move the logfile to a new name (e.g. daemon.log.1). This maintains the current file descriptors, so the daemon continues to log to the file at its new name. 2) Send a signal (SIGHUP) to the daemon. The daemon needs to be configured to properly receive this signal. The responsibility of the daemon is to close its current file descriptors for the log and open new ones at the original location (creating a new file) and then start logging to that one. 3) Optionally compress the old log file and/or remove any log file backups older than a configured number of revisions.
So my question to you is: are you sure that step 2 isn't where it's failing? Because in general, logrotate is pretty simple code and there aren't a lot of opportunities for it to misbehave.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Wednesday, August 04, 2010 12:39:53 pm Stephen Gallagher did opine:
On 08/04/2010 11:35 AM, Gene Heskett wrote:
Greetings list;
2 redhat employees are list as the authors of logrotate in the manpage, so I just sent them a question because it isn't working as expected.
Obvious question: are you sure that the issue is logrotate and not the application whose logs you are trying to rotate?
For most daemons, logrotate works by doing the following:
- Move the logfile to a new name (e.g. daemon.log.1). This maintains
the current file descriptors, so the daemon continues to log to the file at its new name.
Is this not what the copytruncate directive does?
- Send a signal (SIGHUP) to the daemon. The daemon needs to be
configured to properly receive this signal.
Yes, it can be, but for these tests, fetchmail had been killed, as well as the tail -f on the file, so the file s/b be free of any impediments.
I can add those niceties once this is working, because if I add them and they don't work, I at least know it _was_ working.
The responsibility of the daemon is to close its current file descriptors for the log and open new ones at the original location (creating a new file) and then start logging to that one.
Since /var/log seems to be root only territory, I create the original file and chown it to me since fetchmail, running as me, cannot create a new file there. This is why the copytruncate is used, I found it to be much more dependable than the "create 0600 gene:gene" directive, which seems to be rejected because it tries to do that as the user gene who doesn't have perms to create a file in /var/log. FWIW, copytruncate has worked well for exactly this function for several years now.
- Optionally compress the old log file and/or remove any log file
backups older than a configured number of revisions.
So my question to you is: are you sure that step 2 isn't where it's failing? Because in general, logrotate is pretty simple code and there aren't a lot of opportunities for it to misbehave.
That is why I'm asking for help, it seems to be misbehaving. ;-)
-
Gene Heskett -
John W. Linville -
Michael Cronenworth -
Stephen Gallagher