On 2019-09-20 19:36:02 +0200, Christian Göttsche wrote: > > It is only access.log that it doesn't rotate. After last night: > > > > -rw-r----- 1 root adm 308 2019-09-17 16:39:00 access.log > > -rw-r----- 1 root adm 156 2019-09-16 16:31:06 access.log.3.gz > > -rw-r----- 1 root adm 157 2019-09-13 12:36:03 access.log.4.gz > > -rw-r----- 1 root adm 155 2019-09-12 12:25:14 access.log.5.gz > > -rw-r----- 1 root adm 156 2019-09-10 10:33:38 access.log.6.gz > > Can you please run 'logrotate --debug /etc/logrotate.conf' and search > for output regarding to access.log
rotating pattern: /var/log/apache2/*.log after 1 days (14 rotations) empty log files are not rotated, old logs are removed considering log /var/log/apache2/access.log Now: 2019-09-21 02:35 Last rotated at 2019-09-21 00:00 log does not need rotating (log has been rotated at 2019-9-21 0:0, that is not day ago yet) considering log /var/log/apache2/error.log Now: 2019-09-21 02:35 Last rotated at 2019-09-21 00:00 log does not need rotating (log has been rotated at 2019-9-21 0:0, that is not day ago yet) considering log /var/log/apache2/other_vhosts_access.log Now: 2019-09-21 02:35 Last rotated at 2019-02-19 00:00 log does not need rotating (log is empty) not running prerotate script, since no logs will be rotated not running postrotate script, since no logs were rotated > > Now, I still don't understand why the logs are not rotated since > > gzip is actually fine with the date 1904-01-01: this is just a > > warning. Test: > > > > cventin% rm -f test.txt* > > cventin% echo blah > test.txt > > cventin% touch -d 1904-01-01 test.txt > > cventin% ls -l test.txt* > > -rw-r--r-- 1 vlefevre vlefevre 5 1904-01-01 00:00:00 test.txt > > cventin% gzip test.txt > > gzip: test.txt: warning: file timestamp out of range for gzip format > > cventin% ls -l test.txt* > > -rw-r--r-- 1 vlefevre vlefevre 34 1904-01-01 00:00:00 test.txt.gz > > > > i.e. the file got compressed as expected. > > > > Really, this warning does not matter, in particular for log files. > > Thus logrotate should ignore it. > > > > BTW, even if the file could not be compressed, I think that the best > > solution would be to rotate anyway. > > gzip may say warning, but it exits with a value of 2, and prints to stderr. > So logrotate has every reason to think somethings wrong and leave this > file as it is. > I do not think that should be changed. No, a warning is a warning. This is not an error. FYI, from the gzip(1) man page: Exit status is normally 0; if an error occurs, exit status is 1. If a warning occurs, exit status is 2. logrotate should regard 0 and 2 as OK. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
