Hello,
I see that /etc/localtime is symlink to /tmp/localtime which does not exist:
# ls -l /etc/localtime
lrwxrwxrwx 1 root root 14 May 15 10:20 /etc/localtime -> /tmp/localtime
# ls -l /tmp/localtime
ls: /tmp/localtime: No such file or directory
I have logs with multiple timezones:
May 20 07:59:01 gw /usr/sbin/cron[18291]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
May 20 09:59:21 gw kernel: [430381.451226] mv88e6085 f1072004.mdio-mii:10 lan3: Link is Up - 1Gbps/Full - flow control off
May 20 09:59:21 gw kernel: [430381.459716] br-lan: port 4(lan3) entered blocking state
May 20 09:59:21 gw kernel: [430381.465056] br-lan: port 4(lan3) entered forwarding state
May 20 07:59:21 gw netifd: Network device ‘lan3’ link is up
and the /etc/init.d/system script searches for /usr/share/zoneinfo/$zonename
My zone is contained in zoneinfo-europe package. After installing this and running /etc/init.d/system start /tmp/localtime exists, but cron logs are still in UTC
… I’ll reboot again and post the result
Set it via LuCI as it will generate the corresponding timezone and then reboot. Have tried with various zones and it worked, i.e. after the reboot the symlink always been present and no discrepancies in syslog’s timestamps.
The only setting where the symlink is absent is with UTC which is logical.
# ls -l /etc/localtime /tmp/localtime /etc/config/system
-rw------- 1 root root 455 May 21 21:02 /etc/config/system
lrwxrwxrwx 1 root root 14 May 15 10:20 /etc/localtime -> /tmp/localtime
lrwxrwxrwx 1 root root 37 May 21 21:02 /tmp/localtime -> /usr/share/zoneinfo/Europe/Bratislava
which means, I still need to have zoneinfo-europe package installed.
Should I expect different results without the package, or will luci install it for me?
Which version of TurrisOS are you running?
I am in version 3 and the timezone is on /tmp/TZ, and /etc/TZ is a symlink.
Still the above method didn’t work for me.
# ls -l /etc/TZ /tmp/TZ
ls: /tmp/TZ: No such file or directory
lrwxrwxrwx 1 root root 7 May 15 10:20 /etc/TZ -> /tmp/TZ
and times are still inconsistent:
May 22 10:34:40 gw kernel: [ 100.376726] br-lan: port 7(wlan0) entered forwarding state
May 22 08:34:40 gw hostapd: wlan0: interface state DFS->ENABLED
Afterwards the output timestamps in system log are aligned (but apparently this is not solving the root cause of the issue, only the output formatting).
And probably needs to be manually re-applied after each update.
That seems rather a case in point, though it is not even clear whether the strace snippet refers to userland’s logging or some bit of other operation. Best to my understanding:
CLOCK_REALTIME clock measures the amount of time that has elapsed since Epoch time (aka Unix time) which is 00:00:00 January 1, 1970 Greenwich Mean Time (GMT)
= 50.53444181 y | 2,637 w | 18,458 d | 442,985 hrs
more when coded to, apparently it does call only CLOCK_REALTIME and logically logs in UTC, would be different if the userland would call date. Likely the same with other userland you mentioned, e.g. cron.
In which case the log daemon (syslog-ng) would need to be configured to adjust the source entries to the correct TZ.
the syslog() is a C library function that is supposed to log current time in local timezone. Somehow it does not check for local timezone.
This can be considered a bug