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 !
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
found this is dmesg....
[36563.484030] budgie-daemon[16598]: segfault at 0 ip 00007fa4f98e6534 sp 00007ffced3350e0 error 6 in libwnck-3.so.0.3.0[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
Comment Actions
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.
Comment Actions
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.
Comment Actions
I can't seem to turn on automatic date and time!?
Every time I do, it turns itself off again.
Comment Actions
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.
Comment Actions
Thanks @Girtablulu and @JoshStrobl !
Running these 2 commands in Terminal fixed my time:
- sudo rm /var/lib/systemd/timesync
- sudo systemctl restart systemd-timesyncd.service
Comment Actions
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
Comment Actions
I had the same problem and had to manually re-enable systemd-timesyncd.service. Try running these commands:
- sudo systemctl enable systemd-timesyncd.service
- sudo systemctl start systemd-timesyncd.service
Comment Actions
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).
Comment Actions
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:
- sudo rm /var/lib/systemd/timesync
- sudo systemctl restart systemd-timesyncd.service
- sudo systemctl enable systemd-timesyncd.service
- sudo systemctl start systemd-timesyncd.service
Thanks @JoshStrobl I guess I'll leave this for you to close once it's fixed !
Comment Actions
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.