You are not logged in.
Hello everyone! :D
So, I just cannot figure out what is wrong with my system clock, but it just absolutely refuses to change time zones. And yes, Phoenix and Denver are in the same "Standard" time zone, but they have daylight savings in Denver, so it that distinction is important.
Now, here's my output from my timedatectl status
Local time: Tue 2017-03-21 22:20:57 MST
Universal time: Wed 2017-03-22 05:20:57 UTC
RTC time: Wed 2017-03-22 05:20:57
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
And so, naturally, I run sudo timedatectl set-timezone America/Denver
However... the clock on my desktop doesn't change... nor does the output of the command date
Tue Mar 21 22:30:02 MST 2017
Therefore, the first thing you should check is whether or not timedatectl status actually says that the timezone changed...
Local time: Tue 2017-03-21 23:31:02 MDT
Universal time: Wed 2017-03-22 05:31:02 UTC
RTC time: Wed 2017-03-22 05:31:02
Time zone: America/Denver (MDT, -0600)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Well now, that looks right... but just you wait. Give it 30 seconds or so and timedatectl status outputs:
Local time: Tue 2017-03-21 22:31:47 MST
Universal time: Wed 2017-03-22 05:31:47 UTC
RTC time: Wed 2017-03-22 05:31:47
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
What. The. Junk.
Any ideas?
Last edited by steven.gubler (2017-03-24 02:44:38)
Offline
What are you doing for time synching? What is the status of that service?
Offline
I'm guessing your DE has it's own setting and is screwing things up
Online
Thanks for the prompt responses!
First off...
What are you doing for time synching? What is the status of that service?
Here's systemctl list-units | grep time:
rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service
systemd-timesyncd.service loaded active running Network Time Synchronization
time-sync.target loaded active active System Time Synchronized
timers.target loaded active active Timers
logrotate.timer loaded active waiting Daily rotation of log files
man-db.timer loaded active waiting Daily man-db cache update
shadow.timer loaded active waiting Daily verification of password and group files
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
It looks okay, though I wonder why there are 2 different items that look like they deal with time synching...
Second...
I'm guessing your DE has it's own setting and is screwing things up
That is my suspicion too. How would I check for that? (gdm/Gnome 3)
Offline
Offline
I get the exact same behavior from the gnome preferences client as with the command line: No immediate effect on the time, and a few minutes later it switches itself back to phoenix
Offline
The idea was to ensure to turn gnomes auto-timezone off ...
Offline
Oh, hahaha I got you now... haha
Well, mine's not set to auto-detect my timezone so that wouldn't be it... Good suggestion though
Offline
wild guess: disable and stop systemd-timesyncd.service and install ntp and enable/start ntpd.service instead
Offline
Good idea, but it didn't help... I got the same resetting behavior
Offline
Let's try a bigger hammer. First, does the creation date for /etc/localtime change when some unseen hand changes the timezone?
If so, try making that file read only and see if any process chokes. An indication of such might be as subtle as a log entry.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
You could probably monitor /etc/localtime using csysdig
Offline
Apparently my /etc/localtime file doesn't change at all... Checking it before and after setting the new timezone shows that the file wasn't even touched. Probing deeper, I found something else that I missed before: when I type in the command sudo timedatectl set-timezone America/Denver, and then my password, I get
Failed to set time zone: Access denied
with the error code 0x01
If I typed in the exact same command again, I didn't get the error. (I didn't get any affirmation that the deed was done either, but I didn't get an error code so I assumed it worked that time). I tried this logged in as root too, and no difference.
After I wait for timedatectl to start listing my timezone as Phoenix again, the command gives me the error again. I think I didn't notice this before because I would try the command without sudo, it would tell me that my access was denied, so I would try it again with sudo, and it would appear as though it worked.
Either way, I'm really confused... What permissions does timedatectl need to change my timezone that root doesn't have? root is supposed to be all powerful...
Offline
What's the output of 'file /etc/localtime'?
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
/etc/localtime: symbolic link to /usr/share/zoneinfo/America/Phoenix
And it doesn't change at all when I set the zone.
Offline
What if you force it manually with
# ln -sf /usr/share/zoneinfo/America/Denver /etc/localtime
Offline
Sweet! Looks like that did the trick!
If I may inquire further however, why couldn't I change that file through timedatectl?
Offline
You should have been able to do it, it works fine here and I'm guessing that it works fine for everyone else.
What you can do now is test if timedatectl now can change the symlink.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Nope, still can't change it. Either way though, I suppose that it's "fixed". Thank you all so much!
Offline
I'd suggest to strace timedatectl to see what fails exactly - there *is* some problem which might range beyond this symptom.
Offline