Does setting the system time back impair logrotate operation?

Question

I'm working on an embedded linux system where the root filesystem is mounted from an SDcard. Although many systems like this just mount /var/log on a ramdisk, I'd like to save the logs to the SDcard for recording important events, so I left logrotate operational as usual so the SDcard is not filled up completely.

Unfortunately, this system doesn't have a battery backing up the RTC, so if the system is powered down and up again the system time goes back to Jan 1st 1970. In this situation, I ran logrotate once and then checked the logrotate configuration with logrotate -d /etc/logrotate.conf:

# logrotate -d /etc/logrotate.conf 
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file syslog
reading config info for /var/log/cron /var/log/debug /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler /var/log/syslog 
reading config info for /var/log/wtmp 
reading config info for /var/log/btmp 
error: bad year 1970 for file /var/log/syslog in state file /var/lib/logrotate.status

Handling 3 logs

rotating pattern: /var/log/cron /var/log/debug /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler /var/log/syslog  weekly (4 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/cron
  log does not need rotating
considering log /var/log/debug
  log does not need rotating
considering log /var/log/maillog
  log does not need rotating
considering log /var/log/messages
  log does not need rotating
considering log /var/log/secure
  log does not need rotating
considering log /var/log/spooler
  log does not need rotating
considering log /var/log/syslog
  log does not need rotating
not running postrotate script, since no logs were rotated

rotating pattern: /var/log/wtmp  monthly (1 rotations)
empty log files are rotated, only log files >= 1048576 bytes are rotated, old logs are removed
considering log /var/log/wtmp
  log does not need rotating

rotating pattern: /var/log/btmp  monthly (1 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/btmp
  log does not need rotating
error: could not read state file, will not attempt to write into it

Note that it complains that syslog has a bad year 1970 in logrotate status file /var/log/logrotate.status, which shows like this:

logrotate state -- version 2
"/var/log/syslog" 1970-1-1
"/var/log/debug" 1970-1-1
"/var/log/wtmp" 1970-1-1
"/var/log/spooler" 1970-1-1
"/var/log/btmp" 1970-1-1
"/var/log/maillog" 1970-1-1
"/var/log/httpd/*_log" 1970-1-1
"/var/log/wpa_supplicant.log" 1970-1-1
"/var/log/secure" 1970-1-1
"/var/log/mcelog" 1970-1-1
"/var/log/messages" 1970-1-1
"/var/log/cron" 1970-1-1
"/var/log/vsftpd.log" 1970-1-1

And in the end it says it will not attempt to write into the state file, so now I'm worried if that means the logs won't be rotated correctly. Does anyone know what happens to logrotate when something like this occurs?

The chance of power failing where the system will be installed is low, so I prefer to leave time set correctly, but I'd really like to confirm that, in the event it fails, logrotate won't be screwed up.

Answer 1

The logrotate status file is used to keep track of when a daily log was last rotated. It seems to be willing to write a bogus date like 1970, or 1907 in the case of one embedded system of mine. However when it is next run, it rejects the date in it's own status file and doesn't rotate logs.

I've worked around this by just deleting the status file. This means that when logrotate is next run, it'll assume that it doesn't need to rotate logs for another day, which is fine by me.

A better solution would be to modify the logrotate cron script to first check that the clock is synchronized with ntpq / ntpdate. In fact the easiest way I can think to fit this into a script is to use check_ntp_time in the standard nagios-plugins distribution, like /usr/lib/nagios/plugins/check_ntp_time -H pool.ntp.org

Then just check that the return code is 0 before allowing logrotate to run.

You could also put a call to ntpdate in your logrotate cron script, or in your startup scripts.

On top of this, make sure cron is set up to send you email when cron jobs fail; easiest way to make this possible is to install ssmtp.