Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#47716 - [linux] Time and date incorrect when waking from suspend

Attached to Project: Arch Linux
Opened by Craig (cj0nes) - Monday, 11 January 2016, 19:30 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 03 October 2017, 02:37 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Time and date are wrong upon returning from suspend.
It only seems to occur if computer has been in suspend for a little while.
I tried to suspend then immediately wake up and the time and date are correct.

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
1. Suspend computer for 5+ mins.
2. Wake up and time and date are incorrect.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Tuesday, 03 October 2017, 02:37 GMT
Reason for closing:  No response
Comment by Andreas Radke (AndyRTR) - Tuesday, 12 January 2016, 16:38 GMT
Make sure your BIOS cmos battery isn't empty. Provide some logs. Do you run some time syncing daemon?
Comment by Craig (cj0nes) - Wednesday, 13 January 2016, 02:28 GMT
Checked my CMOS battery, it's fine. Did not have a time sync daemon running, I do now. Suppose it's a workaround, but not really fixing the issue. What is the location of the logs I should provide?
Comment by Doug Newgard (Scimmia) - Tuesday, 19 January 2016, 23:34 GMT
What is the output of `timedatectl` after this happens?
Comment by Craig (cj0nes) - Wednesday, 20 January 2016, 19:31 GMT
Failed to query server: Invalid argument
Comment by Doug Newgard (Scimmia) - Wednesday, 20 January 2016, 20:54 GMT
That point to something more serious than just a time problem. System fully up to date? Booting with systemd? How about some logs?
Comment by Andreas Radke (AndyRTR) - Friday, 22 January 2016, 18:42 GMT
/usr/bin/timedatectl is owned by systemd 228-3... No support for systemd-less systems!
Comment by Craig (cj0nes) - Friday, 22 January 2016, 23:26 GMT
Yes, my system is fully up to date. I'm using systemd. How should I access the logs?
Comment by Doug Newgard (Scimmia) - Saturday, 23 January 2016, 02:16 GMT
journalctl and dmesg
Comment by Doug Newgard (Scimmia) - Monday, 25 January 2016, 15:22 GMT
ping?
Comment by Craig (cj0nes) - Monday, 25 January 2016, 23:48 GMT
It hasn't been doing it the past few days, I'm watching/waiting for it. Will update if it magically fixed itself. Thank you for your patience.
Comment by Craig (cj0nes) - Friday, 29 January 2016, 19:08 GMT
It did it again. Attached are some logs. I trimmed the logs down to before and after it happened.
   journalctl2.txt (11.4 KiB)
   dmesg2.txt (6.5 KiB)
Comment by Doug Newgard (Scimmia) - Saturday, 30 January 2016, 04:44 GMT
Interesting, it appears to be happening right before you enter sleep. You started dmesg a bit late, is there a jump in the time there as well? I was thinking this could be systemd, but it does appear to be kernel.

Edit: it would also be interesting to know if your uptime changes. It's possible the kernel is loosing track of when the system was booted.
Comment by Craig (cj0nes) - Monday, 01 February 2016, 13:41 GMT
I'm not sure what to look for in the dmesg log. I attached the full, untrimmed log. Is there a way I can track uptime?
   dmesg.txt (94.4 KiB)
Comment by Doug Newgard (Scimmia) - Monday, 01 February 2016, 16:08 GMT
There is a jump in the log, but only of 10 minutes or so. I would take this upstream, something is really screwy with the kernel time system here. I'm guessing `uptime` would show the correct times.

Edit: Wait, RTC is in localtime? That shouldn't cause this, but it does cause some strangeness. Try setting that up correctly in UTC.
Comment by Craig (cj0nes) - Tuesday, 02 February 2016, 18:53 GMT
Ran uptime and trimmed the log.

Edit: I previously had "timedatectl" set to UTC mode, but it was still doing it. I can switch back if it helps.
   uptime2.txt (17.8 KiB)
Comment by Craig (cj0nes) - Tuesday, 02 February 2016, 18:59 GMT
Lol, literally right after I edited my last comment, I ran "timedatectl set-local-rtc 0" and after I ran "timedatectl", it tells me "Failed to query server: Invalid argument". Same error as above. So, seems there's a circular problem here...
Comment by Craig (cj0nes) - Friday, 05 February 2016, 13:34 GMT
I should mention, I upgraded to kernel 4.4.1 and the problem is still prevalent.
Comment by Andreas Radke (AndyRTR) - Saturday, 27 August 2016, 12:11 GMT
I guess this was a local hardware/user setup issue. Can we close this one?

Loading...