Author Topic: logrotate won't  (Read 499 times)

Offline Almost-retired

  • Sr. Member
  • ****
  • Posts: 252
    • What keeps Gene out of the bars
logrotate won't
« on: August 04, 2010, 10:12:34 AM »
Greets all;

I am having a logrotate problem, 2 of them actually.

1. Added scripts installed in /etc/logrotate.d only work if -f is set on the cli, using syntax like "logrotate -dvf ./fetchmail" while in the logrotate.d directory.

2. the copytruncate directive is being ignored.

Sample script called fetchmail:
# Logrotate file for fetchmail.log & procmail.log                                                                                                                                       
# by Gene Heskett                                                                                                                                                                       
/var/log/fetchmail.log {                                                                                                                                                               
        size 250k
        copytruncate
        missingok
        compress
        notifempty
        weekly
        rotate 5
}

There are obviously more pre and postrotate stuff I need to add, to kill and restart the fetchmail daemon for instance.  But I'd like to get this to work before I add something else that could break it again.

ATM: ls -l /var/log/fetchmail*
-rw-r--r-- 1 gene gene 1436098 2010-08-04 11:07 /var/log/fetchmail.log
-rw-r--r-- 1 gene gene  176693 2010-08-01 04:02 /var/log/fetchmail.log.1.gz

This after logrotate was invoked with the -dvf options on the 1st of August.

Can anyone see the error of my ways here?

Thanks.

Cheers, Gene

Offline Almost-retired

  • Sr. Member
  • ****
  • Posts: 252
    • What keeps Gene out of the bars
Re: logrotate won't [SOLVED]
« Reply #1 on: August 18, 2010, 07:59:29 PM »
In this case it was pebkac, I failed the RTFM test. :(  It seems logrotate will not actually do anything in the debugging mode, but it works in Sunday mornings almost as expected.  I say almost, because linux, when using the truncateinplace option, does NOT deallocate the disk used by the file, so to an ls l, it still looks like the monster file it was.  Thanks to all those that didn't reply. ;)