NAS542 cron local time rsync

Victorian_Avgvstvs

I was brought to my issue by cron's bad behaving, which had not start my jobs(may be system's jobs too). It's about both system and entware cron(yes, I was at neighboring topic). Somehow I noticed that system time(after command "date") is different from what web interface is showing. Keeping in mind you can set your timezone through web inteface, it doesn't affect on main system. The timezone is set on UTC but not my local time. Ok, hold your poofs, I handled it with ffp startup script sym-linking /etc/localtime to wanted timezone, but since that special moment cron actually does its jobs including right-after-start "ntpdate_sync.sh", which sets my timezone back to UTC. LMAO.

My ntp-server is my router, if that's important.

I'm stumped now.

Mijzelf

Timezone is a complicated matter, from some point of view. Most (all?) programs use the time and date functions of libc. For local time libc reads /etc/localtime, which is normally a symlink to one of the files in /usr/share/zoneinfo/, which is created to set the 'system' local timezone. On the NAS it's pointing to /etc/MyZone, which is created at boottime. I suppose it's copied from /usr/local/zoneinfo/, but I don't know why /etc/localtime doesn't point directly to that file.

If the TZ environment variable is set, libc uses that, instead of /etc/localtime. That is how different timezones for different users are implemented. Just a TZ= in ~/.bashrc or ~/.profile. Which means you can run any program in any timezone you like:

TZ="Asia/Hong_Kong" date

This reads the file /usr/share/zoneinfo/Asia/Hong_Kong, and uses that. Unfortunately the directory /usr/share/zoneinfo doesn't exist on the NAS. It's /usr/local/zoneinfo/ here. And firmware libc doesn't read the TZDIR variable either.

You could create a symlink /usr/share/zoneinfo pointing to /usr/local/zoneinfo, but unfortunately /usr is readonly. The directory /usr/share/ is almost empty, and doesn't contain anything important, so there is an easy way around:

su
mount -t tmpfs share /usr/share
ln -s ../local/zoneinfo /usr/share/zoneinfo

TZ="Asia/Hong_Kong" date

Now date should show the HKT timezone. And maybe now your jobs use the right timezone.

Victorian_Avgvstvs

Unfortunately TZ-var way had fail on me. Even full path(/usr/local/zoneinfo/Asia/Hong_Kong; /usr/share/zoneinfo/Asia/Hong_Kong; /i-data/.system/zoneinfo/Asia/Hong_Kong) after TZ= doesn't make a difference. I mean I see after "echo $TZ" what I expect to, but after "date" is UTC still.

I guess I can't struggle zyxel's python scripts settled down behind apache walls.

Here is another plan. May be I should delete ntpdate_sync.sh(ok, rename it, we're humans here), and make ntp sync with core utils if there are any, or in other way with entware utils.

Could you please point me out what have I need to make ntp sync. And how could both these procedures affect on web interface shell functioning?

Mijzelf

Unfortunately TZ-var way had fail on me. Even full
path(/usr/local/zoneinfo/Asia/Hong_Kong;
/usr/share/zoneinfo/Asia/Hong_Kong;
/i-data/.system/zoneinfo/Asia/Hong_Kong) after TZ= doesn't make a
difference. I mean I see after "echo $TZ" what I expect to, but after
"date" is UTC still.

Did you use the mount trick I showed you? On my NAS520 it works, and strace shows date actually reads that Hong_Kong file.

Here is another plan.

Fiddling with ntp sync isn't going to help you, unless you are going to do nasty tricks like setting the system time to your timezone. An ntp client sets the system time to UTC. No timezones are involved. While implementing something like

ntpdate || exit 0
let utc=$(date +%s)
let mytz=$(($utc + 7200))
date -s $mytz

seems to solve your problem, it's asking for other trouble. Protocols like TLS assume the clock on both ends are the same, within certain limits. If you set the clock on you PC a year behind or ahead, you can't access any https sites anymore. And the timestamps on files access via samba are in server time, not client time. The client adds it's timezone before showing.

About the python code, my Tweaks package has a function (in Disable daemons) to purge the python code and use ntpdate instead (which is also on the box). That works fine, and I don't know why python was used. As far as I can see it just adjusts the system time, without callbacks to the firmware, or something like that.

Victorian_Avgvstvs

"About the python code, my Tweaks package has a function (in Disable daemons)"
OMG i'm stooped.
Shame on me, I was even posting Tweaks screenshot at rsync-cron topic, but totally forgot about unneeded deamons. And ntpdate_sync.sh is pretty simple now: /sbin/ntpdate $myrouter.

Good news: I found out why my scripts from cron didn't started. It was actually rsync only which didn't, and it was needed just his full path to. It turned out cron executes in like fifth dimension and doesn't see variables, at least PATH with /ffp/bin, where my rsync is. Here https://serverfault.com/questions/554124/why-rsync-is-not-working-with-crontab man kicked me to that. Unfortunately his straight advice didn't work on me. It can be cron at start sees PATH from /etc/profile(without /ffp/bin), then FFP starts and rewrites PATH.

And another good news: I found the best place for TZ. It is /ffp/etc/profile. But somehow date still shows me UTC time. You probably had guess the reason why already. FFP. Every time I was entering NAS cli I was look at the ffp shell headline and didn't see it. So my date is actually /ffp/bin/date. But my /bin/date now shows my actual time WITH my timezone, not GMT.
And have no doubt I tryed the trick you advised me, and I know now, that while have no $TZ, /ffp/bin/date needs /etc/TZ, and I made a sym-limk /etc/TZ from wanted timezone, but stil I can't get my time from /ffp/bin/date. Probably I should add TZ= to /etc/profile, but I'm afraid to mess it up.

Mijzelf

Probably I should add TZ= to /etc/profile, but I'm afraid to mess it up.

No need for the fear. All files in /etc/profile (with exception of the zyxel directory) are on a ramdrive, and either generated on boot, or stored in a read-only cpio file inside the kernel (the initramfs). So if you mess it up, just reboot.