Bug 33325

(In reply to Martin Jacqmin from comment #0)
> Description of problem:
> Every weeks or two weeks I notice my computer time is totaly wrong. So I
> decide to sync it again with NTP.
> I go in CCM, then I select NTP and chose the Paris NTP url. Then I validate.
> When I open the windows again the NTP is not saved.
> But my time is updated. It's like the clock is synchronized when I click OK
> but doesn't check regulary.

The first part, that you can't see that NTP has become operational, is bug 28264


However, your clock should be synchronized anyway.

What is the output, in a konsole or terminal, of:

  timedatectl

CC: (none) => marja11

Hello, 

Here is what I got :

[x@localhost ~]$ timedatectl
               Local time: mer. 2024-06-26 11:47:35 CEST
           Universal time: mer. 2024-06-26 09:47:35 UTC
                 RTC time: mer. 2024-06-26 11:47:36
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
[x@localhost ~]$ ^C

Regards,

Hmm, in the original bug, "NTP service" is shown *active*; and "System clock synchronized" is shown 'yes'.
We need to find out here whether the computer time remains correct. Or another way to see whether some mechanism is running.

CC: (none) => lewyssmith
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=28264

What does "systemctl status ntpd.service" show?

IIRC, ntpd will be dropped at some point in favour of chronyd. I'm not
sure of the status of that in regard to mcc.

CC: (none) => davidwhodgins

I runned 'timedatectl set-local-rtc 0' as requested by warning. I don't know if it will solve my problem but here is what I have now. And I also try the command you're asking me above.

[martinjacqmin@localhost ~]$ timedatectl
               Local time: jeu. 2024-06-27 08:50:55 CEST
           Universal time: jeu. 2024-06-27 06:50:55 UTC
                 RTC time: jeu. 2024-06-27 06:50:55
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
[martinjacqmin@localhost ~]$ systemctl status ntpd.service
Unit ntpd.service could not be found.
[martinjacqmin@localhost ~]$

The "timedatectl set-local-rtc 0" tells systemd to expect the real time clock
to be set to utc rather then local time. While it's simpler to keep the rtc
set to utc, there is other software installed that has to know which time is
being used.

Whether the rtc is expected to have utc or local time is specified in
/etc/adjtime, /etc/chrony.conf, and /etc/sysconfig/clock, with different
software checking in different places. There are likely other places too,
but those are the ones I'm aware of from what I have installed on my systems.
Those are for settings at the system level. As the user level, there are
various settings that depend on which desktop environment is being used and
which applications are in use.

Since the timedatectl was run as a regular user, I don't think it will survive
a reboot. I'm pretty sure, but have never tested it, that it has to be run as
root to survive a reboot. I keep all of my systems set to utc.

In the terminal, such as konsole, run "su -" and enter the root password, to
be able to run commands as root. The " -" is short for " --login root".
Use the "exit" command to return from running commands as root to running them
as the regular user.

As ntp is not installed, check chrony with "systemctl status chronyd.service".