logrotate.service fails due to bad year (1970)

[funkyboris]

I have the following problem using the logrotate service to keep my journal tidy:

$this->bbcode_second_pass_code('', '
jan 11 00:00:00 example systemd[1]: Starting Rotate log files...
jan 11 00:00:00 example logrotate[19531]: error: bad year 1970 for file /var/log/wtmp in state file /var/lib/logrotate.status
jan 11 00:00:00 example systemd[1]: logrotate.service: main process exited, code=exited, status=1/FAILURE
jan 11 00:00:00 example systemd[1]: Failed to start Rotate log files.
jan 11 00:00:00 example systemd[1]: Unit logrotate.service entered failed state.
jan 11 00:00:00 example systemd[1]: logrotate.service failed.
')

I use the SystemMaxUse=256M in /etc/systemd/journald.conf to instruct logrotate to clean up the logs if they become too large.

Now, this is perhaps a perfectly reasonable behavior for a normal server system running Arch on hardware with a RTC. The Raspberry Pi, however, was not lucky enough to be born with one.

Can anybody recommend settings that will help mitigate this? I could, of course, clean up the logs manually, but i would rather have the service do it if at all possible (That, or get a RTC, which would probably also solve it).

[sdjf]

I am wondering if there is a way to not have the service start until after your Pi has reset it's date to a current one, after rebooting.

Have you just left your Pi in 1970 instead of giving it a current date manually? I have my pi record the current date in unix time every minute or so, and a cron job that checks a few minutes after each hour, to make sure the date is a current one, and which resets it to the last date recorded, if it detects an old date. the time is off a little bit, but it is good enough to make my logs easier to decipher, once the time is changed automatically.

[pepedog]

There is a package called fake-hwclock

[pepedog]

Test