Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

> 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


> 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.

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2019-09-19 11:27:37 +0200, Vincent Lefevre wrote:
> So, the rotation occurs at midnight, according to the systemd timer.
> This conflicts with the crontab configuration.

Hmm... I see that /etc/cron.daily/logrotate disables the rotation
by cron in case of systemd. So, the issue with the missing mail is
due to the systemd timer, which just outputs the error message in
the logs (not sufficient as a manual intervention is needed). In
any case, this is different from the original bug. I've reported
a new bug for this particular problem.

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2019-09-19 11:03:36 +0200, Vincent Lefevre wrote:
> On 2019-09-18 12:52:32 +0200, Christian Göttsche wrote:
> > If yes, please share 'systemctl status logrotate.timer' and
> > 'journalctl -u logrotate' (the most recent part of it).
> 
> ● logrotate.timer - Daily rotation of log files
>Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor 
> preset: enabled)
>Active: active (waiting) since Thu 2019-09-19 10:25:10 CEST; 32min ago
>   Trigger: Fri 2019-09-20 00:00:00 CEST; 13h left
>  Docs: man:logrotate(8)
>man:logrotate.conf(5)
> 
> Sep 19 10:25:10 cventin systemd[1]: Started Daily rotation of log files.
> 
> [...]
> Sep 16 00:00:01 cventin systemd[1]: Starting Rotate log files...
> Sep 16 00:00:02 cventin systemd[1]: logrotate.service: Succeeded.
> Sep 16 00:00:02 cventin systemd[1]: Started Rotate log files.
> Sep 17 00:00:01 cventin systemd[1]: Starting Rotate log files...
> Sep 17 00:00:03 cventin systemd[1]: logrotate.service: Succeeded.
> Sep 17 00:00:03 cventin systemd[1]: Started Rotate log files.
> Sep 18 00:00:01 cventin systemd[1]: Starting Rotate log files...
> Sep 18 00:00:01 cventin logrotate[16206]: error: Compressing program wrote 
> following message to stderr when compressing log /var/log/apache2/error.log.1:
> Sep 18 00:00:01 cventin logrotate[16206]: gzip: stdin: warning: file 
> timestamp out of range for gzip format
> Sep 18 00:00:01 cventin logrotate[16206]: error: failed to compress log 
> /var/log/apache2/error.log.1
> Sep 18 00:00:02 cventin systemd[1]: logrotate.service: Main process exited, 
> code=exited, status=1/FAILURE
> Sep 18 00:00:02 cventin systemd[1]: logrotate.service: Failed with result 
> 'exit-code'.
> Sep 18 00:00:02 cventin systemd[1]: Failed to start Rotate log files.
> Sep 19 00:00:01 cventin systemd[1]: Starting Rotate log files...
> Sep 19 00:00:02 cventin logrotate[19728]: error: Compressing program wrote 
> following message to stderr when compressing log /var/log/apache2/error.log.1:
> Sep 19 00:00:02 cventin logrotate[19728]: gzip: stdin: warning: file 
> timestamp out of range for gzip format
> Sep 19 00:00:02 cventin logrotate[19728]: error: failed to compress log 
> /var/log/apache2/error.log.1
> Sep 19 00:00:02 cventin systemd[1]: logrotate.service: Main process exited, 
> code=exited, status=1/FAILURE
> Sep 19 00:00:02 cventin systemd[1]: logrotate.service: Failed with result 
> 'exit-code'.
> Sep 19 00:00:02 cventin systemd[1]: Failed to start Rotate log files.

So, the rotation occurs at midnight, according to the systemd timer.
This conflicts with the crontab configuration.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2019-09-18 12:52:32 +0200, Christian Göttsche wrote:
> Please share your current setup:
> Debian version: (old-stable | stable | testing | unstable)

unstable

> Logrotate version: (logrotate --version)

logrotate 3.15.1

Default mail command:   /usr/bin/mail
Default compress command:   /bin/gzip
Default uncompress command: /bin/gunzip
Default compress extension: .gz
Default state file path:/var/lib/logrotate/status
ACL support:yes
SELinux support:yes

> Please share your cronjob config '/etc/cron.daily/logrotate'

#!/bin/sh

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
exit 0
fi

# this cronjob persists removals (but not purges)
if [ ! -x /usr/sbin/logrotate ]; then
exit 0
fi

/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit $EXITVALUE

(This is the default one.)

> Are you using systemd?

Yes, this machine does.

> If yes, please share 'systemctl status logrotate.timer' and
> 'journalctl -u logrotate' (the most recent part of it).

● logrotate.timer - Daily rotation of log files
   Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor preset: 
enabled)
   Active: active (waiting) since Thu 2019-09-19 10:25:10 CEST; 32min ago
  Trigger: Fri 2019-09-20 00:00:00 CEST; 13h left
 Docs: man:logrotate(8)
   man:logrotate.conf(5)

Sep 19 10:25:10 cventin systemd[1]: Started Daily rotation of log files.

[...]
Sep 16 00:00:01 cventin systemd[1]: Starting Rotate log files...
Sep 16 00:00:02 cventin systemd[1]: logrotate.service: Succeeded.
Sep 16 00:00:02 cventin systemd[1]: Started Rotate log files.
Sep 17 00:00:01 cventin systemd[1]: Starting Rotate log files...
Sep 17 00:00:03 cventin systemd[1]: logrotate.service: Succeeded.
Sep 17 00:00:03 cventin systemd[1]: Started Rotate log files.
Sep 18 00:00:01 cventin systemd[1]: Starting Rotate log files...
Sep 18 00:00:01 cventin logrotate[16206]: error: Compressing program wrote 
following message to stderr when compressing log /var/log/apache2/error.log.1:
Sep 18 00:00:01 cventin logrotate[16206]: gzip: stdin: warning: file timestamp 
out of range for gzip format
Sep 18 00:00:01 cventin logrotate[16206]: error: failed to compress log 
/var/log/apache2/error.log.1
Sep 18 00:00:02 cventin systemd[1]: logrotate.service: Main process exited, 
code=exited, status=1/FAILURE
Sep 18 00:00:02 cventin systemd[1]: logrotate.service: Failed with result 
'exit-code'.
Sep 18 00:00:02 cventin systemd[1]: Failed to start Rotate log files.
Sep 19 00:00:01 cventin systemd[1]: Starting Rotate log files...
Sep 19 00:00:02 cventin logrotate[19728]: error: Compressing program wrote 
following message to stderr when compressing log /var/log/apache2/error.log.1:
Sep 19 00:00:02 cventin logrotate[19728]: gzip: stdin: warning: file timestamp 
out of range for gzip format
Sep 19 00:00:02 cventin logrotate[19728]: error: failed to compress log 
/var/log/apache2/error.log.1
Sep 19 00:00:02 cventin systemd[1]: logrotate.service: Main process exited, 
code=exited, status=1/FAILURE
Sep 19 00:00:02 cventin systemd[1]: logrotate.service: Failed with result 
'exit-code'.
Sep 19 00:00:02 cventin systemd[1]: Failed to start Rotate log files.

> > It seems really broken, worse than expected. First, I did not get
> > any error via cron, and the error logs did not change:
> >
> > -rw-r- 1 root adm 306 1904-01-01 00:00:00 error.log
> > -rw-r- 1 root adm 440 1904-01-01 00:00:00 error.log.1
> > -rw-r- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
> > -rw-r- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
> > -rw-r- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
> > -rw-r- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
> > [...]
> 
> That the logs do not change is expected, as gzip failed;
> if you using systemd you should see some error messages in the journal.

Yes, this is the case. But cron should have sent a mail with these
error messages, and I haven't received such a mail.

> > Worse, this seemed to have interrupted the rotation of the
> > access logs (or is this a different bug?):
> >
> > -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.2.gz
> > -rw-r- 1 root adm 157 2019-09-13 12:36:03 access.log.3.gz
> > -rw-r- 1 root adm 155 2019-09-12 12:25:14 access.log.4.gz
> > -rw-r- 1 root adm 156 2019-09-10 10:33:38 access.log.5.gz
> > [...]
> 
> This is indeed unexpected, in my tests logrotate continues to rotate
> other logs. (see https://paste.debian.net/1101399/)

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 

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

Please share your current setup:
Debian version: (old-stable | stable | testing | unstable)
Logrotate version: (logrotate --version)
Please share your cronjob config '/etc/cron.daily/logrotate'
Are you using systemd?
If yes, please share 'systemctl status logrotate.timer' and
'journalctl -u logrotate' (the most recent part of it).


> It seems really broken, worse than expected. First, I did not get
> any error via cron, and the error logs did not change:
>
> -rw-r- 1 root adm 306 1904-01-01 00:00:00 error.log
> -rw-r- 1 root adm 440 1904-01-01 00:00:00 error.log.1
> -rw-r- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
> -rw-r- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
> -rw-r- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
> -rw-r- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
> [...]

That the logs do not change is expected, as gzip failed;
if you using systemd you should see some error messages in the journal.

> Worse, this seemed to have interrupted the rotation of the
> access logs (or is this a different bug?):
>
> -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.2.gz
> -rw-r- 1 root adm 157 2019-09-13 12:36:03 access.log.3.gz
> -rw-r- 1 root adm 155 2019-09-12 12:25:14 access.log.4.gz
> -rw-r- 1 root adm 156 2019-09-10 10:33:38 access.log.5.gz
> [...]

This is indeed unexpected, in my tests logrotate continues to rotate
other logs. (see https://paste.debian.net/1101399/)


p.s.:
To avoid these timestamps you can use the configuration option 'prerotate'.
Otherwise it's on gzip.

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2019-09-17 15:32:10 +0200, Vincent Lefevre wrote:
> OK, I understand the reason with the upstream discussion. I think
> that the best thing is to try to reproduce the issue under the
> usual conditions (i.e. via cron and without trying to change the
> status file). So, on some machine, I've set in /var/log/apache2
> 
>   touch -d 19040101 error.log error.log.1
> 
> so that I now have
> 
> -rw-r- 1 root adm 306 1904-01-01 00:00:00 error.log
> -rw-r- 1 root adm 440 1904-01-01 00:00:00 error.log.1
> -rw-r- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
> -rw-r- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
> -rw-r- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
> -rw-r- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
> [...]
> 
> and let's see what happens. If I understand correctly, I should
> get an error each time cron.daily scripts will run, in particular
> tomorrow and the day after tomorrow. After confirming that, I can
> fix the timestamps manually.

It seems really broken, worse than expected. First, I did not get
any error via cron, and the error logs did not change:

-rw-r- 1 root adm 306 1904-01-01 00:00:00 error.log
-rw-r- 1 root adm 440 1904-01-01 00:00:00 error.log.1
-rw-r- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
-rw-r- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
-rw-r- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
-rw-r- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
[...]

Worse, this seemed to have interrupted the rotation of the
access logs (or is this a different bug?):

-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.2.gz
-rw-r- 1 root adm 157 2019-09-13 12:36:03 access.log.3.gz
-rw-r- 1 root adm 155 2019-09-12 12:25:14 access.log.4.gz
-rw-r- 1 root adm 156 2019-09-10 10:33:38 access.log.5.gz
[...]

Notice the lack of "access.log.1". As a comparison, on another
machine, I currently have:

-rw-r- 1 root adm0 2019-09-18 00:00:01 access.log
-rw-r- 1 root adm  751 2019-09-17 18:06:56 access.log.1
-rw-r- 1 root adm  164 2019-09-16 01:09:27 access.log.2.gz
-rw-r- 1 root adm  202 2019-09-15 02:47:33 access.log.3.gz
-rw-r- 1 root adm  204 2019-09-10 09:41:04 access.log.4.gz
-rw-r- 1 root adm  196 2019-09-06 09:51:57 access.log.5.gz
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2019-09-08 17:22:15 +0200, Christian Göttsche wrote:
> Control: tags -1 moreinfo unreproducible
> 
> The timestamp in the state file stands for the last attempt to rotate
> the file (see https://github.com/logrotate/logrotate/issues/223), so
> an update of it is fine.
> 
> In message #27 logrotate probably did not show any error cause the
> option 'daily' was used; when forcing a rotation (--force) an error
> message is also shown in subsequently runs.

OK, I understand the reason with the upstream discussion. I think
that the best thing is to try to reproduce the issue under the
usual conditions (i.e. via cron and without trying to change the
status file). So, on some machine, I've set in /var/log/apache2

  touch -d 19040101 error.log error.log.1

so that I now have

-rw-r- 1 root adm 306 1904-01-01 00:00:00 error.log
-rw-r- 1 root adm 440 1904-01-01 00:00:00 error.log.1
-rw-r- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
-rw-r- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
-rw-r- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
-rw-r- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
[...]

and let's see what happens. If I understand correctly, I should
get an error each time cron.daily scripts will run, in particular
tomorrow and the day after tomorrow. After confirming that, I can
fix the timestamps manually.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

Control: tags -1 - fixed-upstream

> Control: tags -1 moreinfo unreproducible
>
> The timestamp in the state file stands for the last attempt to rotate
> the file (see https://github.com/logrotate/logrotate/issues/223), so
> an update of it is fine.
>
> In message #27 logrotate probably did not show any error cause the
> option 'daily' was used; when forcing a rotation (--force) an error
> message is also shown in subsequently runs.

This time also sending to the submitter...

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

Control: tags -1 moreinfo unreproducible

The timestamp in the state file stands for the last attempt to rotate
the file (see https://github.com/logrotate/logrotate/issues/223), so
an update of it is fine.

In message #27 logrotate probably did not show any error cause the
option 'daily' was used; when forcing a rotation (--force) an error
message is also shown in subsequently runs.

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2018-08-22 23:44:05 +0200, Christian Göttsche wrote:
> I tested logrotate version 3.14.0-2 with an ancient logfile from 1904
> and it got rotated. Also no such date should show up in the state file
> (only rotation times, not file mtimes).
> Can you reproduce this issue with logrotate 3.14.0-2 or newer?
> Please post a logrotate state file with such ancient dates.

This is old, and I'm not sure that the issue is the same.
And I no longer have the old machine to test under the
same conditions. But...

/var/lib/logrotate/status contains:

"/var/log/lpr.log" 2018-1-23-12:00:00

(i.e. a date sufficiently old to trigger a rotate).

# ls -l /var/log/lpr.log*
-rw-r- 1 root adm  5 1904-01-01 00:00:00 /var/log/lpr.log
-rw-r- 1 root adm  4 1904-01-01 00:00:00 /var/log/lpr.log.1
-rw-r- 1 root adm 60 2015-06-18 18:41:13 /var/log/lpr.log.2.gz
# /usr/sbin/logrotate /etc/logrotate.conf
error: Compressing program wrote following message to stderr when compressing 
log /var/log/lpr.log.1:
gzip: stdin: warning: file timestamp out of range for gzip format
error: failed to compress log /var/log/lpr.log.1
# ls -l /var/log/lpr.log*
-rw-r- 1 root adm  5 1904-01-01 00:00:00 /var/log/lpr.log
-rw-r- 1 root adm  4 1904-01-01 00:00:00 /var/log/lpr.log.1
-rw-r- 1 root adm 60 2015-06-18 18:41:13 /var/log/lpr.log.2.gz
# /usr/sbin/logrotate /etc/logrotate.conf
# ls -l /var/log/lpr.log*
-rw-r- 1 root adm  5 1904-01-01 00:00:00 /var/log/lpr.log
-rw-r- 1 root adm  4 1904-01-01 00:00:00 /var/log/lpr.log.1
-rw-r- 1 root adm 60 2015-06-18 18:41:13 /var/log/lpr.log.2.gz

I don't know whether this was the cause of the failure of the
rotations in the past. But the error has disappeared and the
logs files are no longer rotated. This is inconsistent.

In case of gzip error, logrotate should either ignore it and rotate
the files, or it should keep the old date in /var/lib/logrotate/status
(I assume that the user should see the repeating error in cron
e-mails).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

Control: tags -1 moreinfo unreproducible

Hi,
I tested logrotate version 3.14.0-2 with an ancient logfile from 1904
and it got rotated. Also no such date should show up in the state file
(only rotation times, not file mtimes).
Can you reproduce this issue with logrotate 3.14.0-2 or newer?
Please post a logrotate state file with such ancient dates.

Best regards
Christian Göttsche

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

On 2008-11-03 04:04:50 +, Paul Martin wrote:
 That shouldn't be possible without getting an error:
 
 if ((year != 1900)  (year  1970 || year  2100)) {
 message(MESS_ERROR, bad year %d for file %s in state file %s\n,
 year, argv[0], stateFilename);
 fclose(f);
 return 1;
 }

Sorry, I've tried and I get an error (in fact, after checking in the
shell history, it seems that I hadn't tested logrotate with these 1904
dates: when I noticed all these 1904 dates, I just removed the status
file as I thought it would have been simpler than fixing all these
dates, then ran logrotate, and I didn't get an error for this missing
status file, but this may be expected).

BTW, I should have seen this error in the anacron messages (a bit
hidden amongst other spurious error messages, unfortunately).

Now, the fact that 1904 is ignored is quite annoying. Well, the best
solution would be that logrotate should never put such an old date in
/var/lib/logrotate/status.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Vincent Lefevre]

Package: logrotate
Version: 3.7.1-5
Severity: normal

When /var/lib/logrotate/status has files with date 1904-1-1 (e.g.
/var/log/wtmp), these files are no longer rotated. I don't even
get any error message.

Note: the 1904-1-1 is due to the fact that on the PowerBook G4,
when the battery is empty, the date is reset to 1904-01-01.

-- Package-specific info:
Contents of /etc/logrotate.d
total 64
-rw-r--r-- 1 root root 293 2008-01-18 05:48:15 apache2
-rw-r--r-- 1 root root  84 2007-10-31 19:58:59 apt
-rw-r--r-- 1 root root  79 2003-06-09 23:55:29 aptitude
-rw-r--r-- 1 root root 215 2008-04-16 10:14:43 checksecurity
-rw-r--r-- 1 root root 133 2002-05-09 22:19:59 distributed-net
-rw-r--r-- 1 root root 111 2005-06-28 16:37:19 dpkg
-rw-r--r-- 1 root root 146 2008-05-02 16:26:55 exim4-base
-rw-r--r-- 1 root root 126 2008-05-02 16:26:55 exim4-paniclog
-rw-r--r-- 1 root root 201 2006-11-12 13:13:19 fail2ban
-rw-r--r-- 1 root root 372 2005-12-23 17:05:35 gnump3d
-rw-r--r-- 1 root root 161 2005-07-08 19:27:20 knockd
-rw-r--r-- 1 root root 101 2005-01-17 04:46:43 mpd
-rw-r--r-- 1 root root  94 2003-10-31 00:34:17 ppp
-rw-r--r-- 1 root root  68 2002-07-01 23:31:43 scrollkeeper
-rw-r--r-- 1 root root 203 2001-12-14 05:32:26 suck
-rw-r--r-- 1 root root 439 2006-06-15 18:40:18 wwwoffle


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages logrotate depends on:
ii  anacron   2.3-13.1   cron-like program that doesn't go 
ii  base-passwd   3.5.19 Debian base system master password
ii  cron  3.0pl1-105 management of regular background p
ii  libc6 2.7-15 GNU C Library: Shared libraries
ii  libpopt0  1.14-4 lib for parsing cmdline parameters
ii  libselinux1   2.0.65-5   SELinux shared libraries

Versions of packages logrotate recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20071201cvs-3 A simple mail user agent

logrotate suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Paul Martin]

On Sun, Nov 02, 2008 at 11:04:23PM +0100, Vincent Lefevre wrote:

 When /var/lib/logrotate/status has files with date 1904-1-1 (e.g.
 /var/log/wtmp), these files are no longer rotated. I don't even
 get any error message.

That shouldn't be possible without getting an error:

if ((year != 1900)  (year  1970 || year  2100)) {
message(MESS_ERROR, bad year %d for file %s in state file %s\n,
year, argv[0], stateFilename);
fclose(f);
return 1;
}

Could you attach your /var/lib/logrotate/status, please?

-- 
Paul Martin [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]