Page MenuHomeSolus

Time messed up after recent updates
Closed, ResolvedPublic


I installed today's updates, I couldn't restart or shut down, so I had to force my laptop off.
After logging in, I noticed the time was wrong. Choosing Europe/Dublin in Time and Date settings didn't help.
My time is 58 minutes behind !

image.png (877×934 px, 101 KB)

Event Timeline

i can also not shutdown after this update.

my time is fine.

found this is dmesg....

[36563.484030] budgie-daemon[16598]: segfault at 0 ip 00007fa4f98e6534 sp 00007ffced3350e0 error 6 in[7fa4f98dd000+25000]
[36563.484043] Code: 43 40 00 00 00 00 48 8b 7b 60 e8 37 7a ff ff 49 8b 44 24 18 48 8b 15 e3 cc 02 00 48 63 08 48 8b 78 70 48 c7 40 60 00 00 00 00 <48> c7 04 ca 00 00 00 00 e8 bf 7f ff ff 49 8b 44 24 18 be 50 00 00

I had this restart/shut down problem before. May be related to the systemd update ?
And the time getting messed up must be specific to Solus Mate.

i'm on budgie and the first time for me, anyway the first time where "shutdown now" didn't work. systemd?

anyway after a forced poweoff in software "poweroff -f" and a reboot everything is now working.

Heh. After rebooting I was off by 10 hours. My system also crashed 10 minutes later.

I can't seem to turn on automatic date and time!?

image.png (216×964 px, 19 KB)

Every time I do, it turns itself off again.

I have the same issue, I dual booted into Windows and Windows changed time to local. I set it back to UTC but the Automatic Date & Time setting keeps resetting to off. Yes, location services are activated. No, I no longer boot to Windows.

mate-user claimed this task.
mate-user added a subscriber: JoshStrobl.

Thanks @Girtablulu and @JoshStrobl !
Running these 2 commands in Terminal fixed my time:

  1. sudo rm /var/lib/systemd/timesync
  2. sudo systemctl restart systemd-timesyncd.service

After restarting, the problem is back ! I tried to run the first command (sudo rm /var/lib/systemd/timesync) but I see this error:
rm: cannot remove '/var/lib/systemd/timesync': Is a directory

I had the same problem and had to manually re-enable systemd-timesyncd.service. Try running these commands:

  1. sudo systemctl enable systemd-timesyncd.service
  2. sudo systemctl start systemd-timesyncd.service
JoshStrobl triaged this task as High priority.
JoshStrobl moved this task from Backlog to System and Configuration Fixes on the Software board.

This is the result of systemd-timesync failing to write the clock file in /var/lib/systemd/timesync/, as in reality prior to v240 (we were on v238, so this applies to us) it was a symlink to ./private/systemd/timesync. The respective clock file cannot be read because the timesync folder itself in /var/lib/systemd/ is owned by root.

These paths are automatically generated by systemd and not something which our package really should be setting up out-of-the-box, since there would be no proper migration of the file contents and the elimination of the private directory for timesync. systemd's "solution" is basically to let distro maintainers handle it, per this bug report, instead of handling the migration themselves, which means we'll need to write a usysconf handler to perform proper migration.

This is going to be slightly more time consuming and likely going to require us to merge some near-complete usysconf rewrite code into our project to ease the implementation (the current usysconf C-based implementation is a mess and completely overengineered).

Thanks @paracetamol ! After running those 2 commands, my time is correct after restarting, just that it's 10 seconds behind now.
Going to Time and Date settings and choosing Europe/Dublin fixes it to exact time, which I'd have to do after every restart if I want exact time.
Looks like just opening Time and Date settings fixed it to exact time, that's not so bad ?
In summary, the 4 commands to run to fix this problem are:

  1. sudo rm /var/lib/systemd/timesync
  2. sudo systemctl restart systemd-timesyncd.service
  3. sudo systemctl enable systemd-timesyncd.service
  4. sudo systemctl start systemd-timesyncd.service

Thanks @JoshStrobl I guess I'll leave this for you to close once it's fixed !

I had the same issue, journalctl showed that lats NTP sync happened on 18. January.
With the 4 steps listed by @mate-user I could fix the issue.

I looked at /etc/systemd/timesyncd.conf and found that the whole config was commented out, but it seems that still the Google NTP is used. Assume there is another config file somewhere else.