Anonymous user reports strange behavior when starting up a 32-bit ARM based device around the time of the epochalypse (UNIX 2038 problem):
Set clock to 2038, e,g, "date 2038-01-14"
Reboot
See what happens -- the behaviour will be strange, e.g, syslog continously restarting, ....
Set clock back to current date, e.g., "date 2021-09-02 11:27"
Reboot unit
Everything seems to be normal
When receiving a syslog message, remote or local, in RFC3164 format, syslogd enters the parsemsg() function and delegates to parsemsg_rfc3164() for processing. In the above scenario the following occurs:
root@right:~# date
Tue Jan 19 03:13:13 UTC 2038
root@right:~# syslogd: syslogd.c:1042: parsemsg_rfc3164: Assertion `year >= tm_now.tm_year - 1' failed.
What we want is for syslogd to handle this more gracefully, possibly fall back to time(NULL), i.e. time now.
Anonymous user reports strange behavior when starting up a 32-bit ARM based device around the time of the epochalypse (UNIX 2038 problem):
When receiving a syslog message, remote or local, in RFC3164 format,
syslogdenters theparsemsg()function and delegates toparsemsg_rfc3164()for processing. In the above scenario the following occurs:What we want is for syslogd to handle this more gracefully, possibly fall back to
time(NULL), i.e. time now.