I discovered this whilst writing the MATE section for the Date & Time page in the Solus Help Center and Josh has requested I file it here. This is a freshly installed copy of Solus MATE in a virtual machine.
Steps to reproduce -
Brisk Menu > Administration > Time and Date > changing the Configuration from "Manual" to "Keep synchronized with Internet servers".
Result - A message asking to install and activate NTP support, as shown in screenshot below.
This is not a solution, but a workaround:
Actually NTP is supported via systemd-timesyncd
Open a terminal and type timedatectl status to check if it's enabled
To configure the NTP servers, edit the file /etc/systemd/timesyncd.conf
As example, here is the ntp servers I defined on my computer.
[Time] NTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.p ool.ntp.org FallbackNTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org
Interesting.
timedatectl status -
NTP enabled: yes NTP synchronized: no
/etc/systemd/timesyncd.conf -
[Time] #NTP= #FallbackNTP=time1.google.com time2.google.com time3.google.com time4.google.com
So it is enabled and I can add ntp servers but the GUI settings dialog doesn't know that.
This is still an issue. Done a fresh MATE installation a few days ago. No iam sitting in Helsinki airport an cannot change my timezone (error when trying to change settings).
In my /etc/systemd/timesyncd.conf where no entries for ntp servers. So i added a few manually and commented every line in. Now ntp sync semms to be working but i cannot change the timezone.
systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2018-11-03 15:19:45 CET; 22min ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 545 (systemd-timesyn)
Status: "Synchronized to time server 95.216.144.226:123 (2.debian.pool.ntp.org)."
Tasks: 2 (limit: 4915)
Memory: 2.0M
CGroup: /system.slice/systemd-timesyncd.service
└─545 /usr/lib/systemd/systemd-timesyncd
Nov 03 15:19:45 citadel systemd[1]: Started Network Time Synchronization.
Nov 03 15:19:45 citadel systemd-timesyncd[545]: request_name_destroy_callback n_ref=1
Nov 03 15:19:46 citadel systemd-timesyncd[545]: Network configuration changed, trying to establish connection.
Nov 03 15:19:46 citadel systemd-timesyncd[545]: Network configuration changed, trying to establish connection.
Nov 03 15:20:15 citadel systemd-timesyncd[545]: Synchronized to time server 95.216.144.226:123 (2.debian.pool.ntp.org).This Issue was already reported in Task 3885
Fixed the problem with :
sudo timedatectl set-timezone Europe/Helsinki
So this is only a workaround. A guess would be that the gui doesnt have the correct rights to do these changes ?
Let me know if you need more informations on this topic.
This was correctly set on my MATE system but thb I don't recall if I did set it myself or not
Well at least i can reproduce this error on my end with the mate edition on my laptop and on vm. Its not a deal breaker but for people who travel a lot it might be annoying.
But i think this can be handled with lower priority.
From a quick look at the mate source code the following files are used for the settings:
/* Files that we look at and that should be monitored */
#define CHECK_NB 5
#define ETC_TIMEZONE "/etc/timezone"
#define ETC_TIMEZONE_MAJ "/etc/TIMEZONE"
#define ETC_RC_CONF "/etc/rc.conf"
#define ETC_SYSCONFIG_CLOCK "/etc/sysconfig/clock"
#define ETC_CONF_D_CLOCK "/etc/conf.d/clock"
#define ETC_LOCALTIME "/etc/localtime"
/* The first 4 characters in a timezone file, from tzfile.h */
#define TZ_MAGIC "TZif"
static char *files_to_check[CHECK_NB] = {
ETC_TIMEZONE,
ETC_TIMEZONE_MAJ,
ETC_SYSCONFIG_CLOCK,
ETC_CONF_D_CLOCK,
ETC_LOCALTIMEBut the files for timezone are not here on my end. Are we missing something here ?
#define ETC_LOCALTIME "/etc/localtime"
Should be what it's using for timezone as the other files aren't used in Solus.
From : name
/* * Code to deal with the system timezone on all distros. * There's no dependency on the SystemTimezone GObject here. * * Here's what we know: * * + /etc/localtime contains the binary data of the timezone. * It can be a symlink to the actual data file, a hard link to the data * file, or just a copy. So we can determine the timezone with this * (reading the symlink, comparing inodes, or comparing content). * * + However, most distributions also have the timezone setting * configured somewhere else. This might be better to read it from there. * * Debian/Ubuntu/Gentoo (new): content of /etc/timezone * Fedora/Mandriva: the ZONE key in /etc/sysconfig/clock * openSUSE: the TIMEZONE key in /etc/sysconfig/clock * Solaris/OpenSolaris: the TZ key in /etc/TIMEZONE * Arch Linux: the TIMEZONE key in /etc/rc.conf * Gentoo (old): the ZONE key in /etc/conf.d/clock * * FIXME: reading the system-tools-backends, it seems there's this too: * Solaris: the TZ key in /etc/default/init * /etc/TIMEZONE seems to be a link to /etc/default/init * * First, some functions to handle those system config files. * */ /* This works for Debian and derivatives (including Ubuntu), and new Gentoo */
This is weird, I had noticed that lately my laptop's time and date isn't syncing for whatever reason, and I am getting the issue from time-admin brings me the same message, while gnome-control-center simply does nothing at all.
timedatectl reports the NTP service as inactive, and activating the service brings no errors, however it not get activated.
Additionally, the time zone was reported as "null", though setting it to my timezone fixed that (I haven't yet rebooted, so I have no idea if it'll stick).
I'm perfectly alright with manually updating the time and date (as many here are, I'm guessing, I'm old enough to remember when phones without online capabilities were the norm), though I am intrigued as to what could be the cause of this, since I did not really mess with anything related to NTP (aside from adding another NTP source).
My timesync.conf had all lines disabled. so I set them up the way I had set them up when adding an NTP provider from my country, but that did not help with activating the service.
I had the same issue as of an update and I managed to resolve the issue by running the following commands:
root@localhost /home/fredrik # rm -rf /var/lib/systemd/timesync root@localhost /home/fredrik # rm -rf /var/lib/private/systemd/timesync root@localhost /home/fredrik # systemctl restart systemd-timesyncd.service