*** Bug 11389 has been marked as a duplicate of this bug. ***

CC: (none) => mbrace700

Another drakclock problem.

CC: (none) => luigiwalser, thierry.vignaud
Source RPM: (none) => drakxtools

David are you sure? the snapshot is the kde panel, drakclock does not use dbus,
so it could not be.

the error on auxiliar sounds odd to me, coling  wdyt?

CC: (none) => anaselli

Ahh, I didn't look at the screenshot.  That's not what you get when you right-click the clock in the Panel, which is what I thought I read for some reason.  That's what you get if you go through systemsettings, which I now see is what they did.

Source RPM: drakxtools => kdebase4-workspace

Hi, David and Angelo,

I indeed did not use drakclock; I used KDE's Systemsettings function "Date and Time" (or something alike, I'm reading in Portuguese) -- so it might be a problem to fix in KDE.

Unfortunately I failed to show it in the attached picture. Sorry.

Renato, that's ok. Mine was to understand where the problem is :)

Please try drakclock or if you want to try also a new tool,
have a look at adminpanel-qt package and run manaclock. 
Then try again the kde Systemsettings one to see if something related 
to drakclock (during the installer phase for instance).

Drakclock is executed (MCC / System / Localization / Configure Date and Time), the hour can be changed, but as we press "OK", nothing happens (i.e. the time is not changed).

Out of curiosity, thinking it could be related, I tried to run MCC / Security / Configure System Security, Permissions and Auditing (I'm translating from Portuguese, who knows what the original English ttext might be?).

Surprisingly, it does not work. There is a dialog stating "Program was not terminated correctly" (maybe "Program ended abnormally"?). Remember we authenticate as root to run MCC. In a Mageia 4 PC, it (MSEC) works as expected.

Installed the adminpanel-qt, used the newly installed Mageia AdminPanel and things didn't work, too.

I'll post a screenshot from the computer with Mageia 5.

Thanks for your attention and help.

Note: After trying to set the time and get the carrot-colored warning about the failure to do so, trying to press OK only causes the same dialog. I'm forced to press Cancel to leave.

Created attachment 6116 [details]
Cannot set time (with new management tool).

manaclock sets only if ok button is pressed :)
I will check what that dbus error means :)
But i wonder if it is related with the fact that you didn't setup the time
zone that (iiuc from Portuguese) is undefined?

> manaclock sets only if ok button is pressed :)

Heh, very funny... I pressed it alright, but the error must be resetting the button... 8-)

> But i wonder if it is related with the fact that you didn't setup the time
zone that (iiuc from Portuguese) is undefined?

Funny that you mentioned "Portuguese".

IIRC, the installation procedure assumed I was in Brazil (from my keyboard option, I suppose, or maybe from my IP). After installing some 4 to 5 times, I may well not have checked to see if it was correct (should be São Paulo).

Well, the computer thinks my hour zone is Antarctica/Troll.

But the real problem is being unable to change it.

@Renato on comment#11 since manaclock is out of the scope of this bug could you please open a bug against adminpanel, i would be happy to investigate better the problems there.
I assumed Portuguese from your snapshot in witch is clearly written "nao
definido" (I don't have the right accents in my italian keyboard for nao sorrry)
that i think is very similar to the italian meaning of "undefined". ;)

As said i would like to understand what does not work and why in adminpanel... so pleas move the bug and we can talk there (or via irc if you are on the channel).

> @Renato on comment#11 since manaclock is out of the scope of this bug could you please open a bug against adminpanel, i would be happy to investigate better the problems there.

OK, I'll do it.

> I assumed Portuguese from your snapshot in witch is clearly written "nao
definido" (I don't have the right accents in my italian keyboard for nao sorrry)
that i think is very similar to the italian meaning of "undefined". ;)

Sem problema! (That's "no problem" in Portuguese)

You assumed correctly, it is indeed Portuguese (but it's about "time"). BTW, for us Brazilians Italian sounds great... 

And I didn't mean to sound angry or something. The word "funny" was to sound like "Hey, that's funny..." (a phrase by Isaac Asimov). For a moment, I thought the system might also have assumed I'm from Portugal because I speak Portuguese, just like you did. And thus would set my computer time/ hour zone to Portugal's during installation.

Really no offense taken. On the contrary, I have to thank you for your kind interest and consideration in solving the problem.

I'll leave this bug open for KDE's Systemsettings, though, as originally intended. If that is planned for removal in Mageia 5, then it might be the case to close it...

I opened bug 15552 about adminpanel-qt.

Additional info:

Using Drakclock (which really is very similar to the KDE interface), I noticed it knows I'm in America/São Paulo, while KDE thinks I'm in Antarctica/Troll.

I found out that, though I cannot change time directly in the digital clock widget (in the panel), it is possible to make it use the America/São Paulo hour zone as "standard", so that the time is correctly displayed.

Later I tried to change my hour zone to America/Rio Branco (a state capital on the other side of the country) in Drakconf and noticed it changed what KDE perceives as "local" to that place.

Then in the digital clock widget I changed the desired hour zone to Europe/San Marino and KDE forgot the Troll station. Now, apparently, it displays my chosen hour zone, the local time as being from Rio Branco, but changed the place name to São Paulo (because it was the formerly chosen hour zone, possibly).

As this borders the unbelievable, I took a screenshot to document it.

It is important to notice that although I didn't choose to sync time with NTP, it seems the option to do so is greyed out in KDE and unchecked in Drakclock.

I guess this can be considered a workaround. That would be a WORKSFORME, but since this is way too important I won't close the bug.

The implications might be deeper, so the decision is best left for the maintainers.

Thank you for your attention; I'll upload the image from the computer with Mageia 5.

Created attachment 6124 [details]
Limited success in changing time. 8o

Well the TZ different is easy to reveal :) drakclock reads that from /etc/sysconfig/clock. So it just writes a setting when you change it and reads it
when it start, doesn't matter what is really configured. So if you changed TZ
from another tool drakclock continue showing the old settings (manaclock should not instead, i hope). (btw i took bug #15552)

https://bugs.mageia.org/show_bug.cgi?id=15552#c3 shows that TZ can be set by manaclock to Sao Paulo

Regarding the panel's digital clock widget behavior:

When changing timezone (*), the time changes after some 2 to 5 seconds.

The timezone label does not change (is not updated) until the KDE session is restarted.

(*) Drakclock and adminpanel-qt can change time zone, though the latter displays an error dialog; KDE Systemsettings cannot change the time zone.

None of the three can change the time, possibly due to time syncing.

I just noticed there's a KDE time zone service which should provide time zone data (including its name, I suppose) to active applications like the digital clock widget. I wonder why this is not working and instead requiring a session restart.

Bug 15552 is about a similar problem (already fixed) with a Mageia clock utility.

The essential problem, which KDE also exhibits, is that NTP time syncing is enabled at install time. This will require re-installation to confirm my memory that I asked NTP not to be used.

In any case, KDE shows a checkbox stating time syncing is not activated -- but it is. Hence no amount of password entering will change the time before syncing is turned off.

From the attached pic (today), there's a popup message stating both ntpdate and rdate are not installed, thus KDE must be thinking no syncing is happening.

Created attachment 6153 [details]
"No NTP utility found. Please instal ntpdate or rdate to enable update(syncing?)"

One possible solution is to remove the setting utility from KDE, since Mageia now has manaclock.

Two places to adjust settings and two tools to install new software will lead to user confusion.

OTOH, keeping KDE elements can reduce the time of adaptation fro newcomers. Having 4 different desktops (KDE, Gnome, Xfce, LXDE) already brings the need to learn a lot; if distributions do not integrate well with those main desktops, Linux will be harder to use IMHO.

Maybe drak/manatools could be called from KDE settings?

On my computer I can solve this problem.

- Use your preferable file manager and go to /etc/localtime. This is a symlink.
- On my pc the target was /mnt/usr/share/zoneinfo/Europe/Berlin
- Delete the "/mnt"
- Then - on my pc - everything is running again, either systray or mcc or KDE settings.

CC: (none) => phartmann

Peter (comment #24) that's pretty odd, the wrong link was a wrong commit i made
in past that used a wrong path on the installer. It should be fixed now...
I cannot find the related bug though. In any case drakclock and manaclock should
have fixed it if used after installation.
How did you had that link?

yes bug #14888

Angelo, I think I got it when I upgraded from mga4 to mga5beta3 using the ISO plus updates afterwards.

Target Milestone: --- => Mageia 5

(In reply to Peter Hartmann from comment #27)
> Angelo, I think I got it when I upgraded from mga4 to mga5beta3 using the
> ISO plus updates afterwards.

I think there was a bug in the timezone package at beta3.  A fresh upgrade from mga4 to mga5rc shouldn't have this issue.

> - Then - on my pc - everything is running again, either systray or mcc or KDE settings.

Peter, everything is already as you say (no "mnt" here). And even so I get an error messages stating "System policies don't allow for changing time and date" or something to that effect.

I believe it would work if I started KDE or Systemsettings as root. I even find reasonable that KDE asks for the root password if it's a system-protected thing.

Renato, from manaclock, that i suppose to work by reading our last discussion
on that subject, could you please tell me if a NTP service is configured and
running and which in the case?

If it is, as i suppose, the reason is that you cannot change time and date if
you decided to sync them, and that is true for all the tools, timedatectl as well.

Created attachment 6423 [details]
Both kde and manaclock time config tools.

Angelo, the thing is I don't remember asking for NTP at installation -- this wasn't important for me at the time.

Currently on my Cauldron test machine, systemd-timesyncd is running. From the attached manaclock screen it seems no time server is defined.

If I uncheck in manaclock the "Ativar NTP" (Activate NTP) checkbox, the KDE utility starts working -- it's annoying, though, because everytime one wants to change time a password is asked.

Whatever the setting in manaclock of Ativar NTP, the checkbox marked "Configurar data e hora automaticamente" (Configure date and time automatically) is always greyed out.

Maybe there's a way to check about NTP servers via command line?

AH, forgot one thing: no matter how many times one enters the password to adjust time in the KDE tool, it still asks it once more when one presses the "Apply" button.

So it is an upstream problem kde tools does not care about systemd-timesyncd exactly as our drakxclock :D 
and systemd-timesyncd is a kind of systemd ntpd

on comment #33 it depends on how set date and time is implemented, iirc manatools
asks twice... for two different operations

I just wish for a more balanced user experience... thank you again, Angelo!

Angelo, I just installed M5 RC to test another bug.

I made sure NTP was NOT activated during installation.

I installed with KDE (the default) and added Mate. No general updates were made (in fact, the red exclamation applet is showing there are updates to be installed).

But I'm testing a fresh RC installation as if just finished.

I regret to inform neither KDE nor drakeconf can alter system time. Probably some NTP sysnc is being done by someone (systemd?) despite KDE and MCC thinking there's no syncing. When asking for the root password to change time KDE already display the dialog with a title stating "System policies do not allow modiification of time and date - PolicyKit1 -KDE".

Manaclock is not available, BTW.

well mate is not kde, i suggest to move to another bug eventually, 
for drakxclock i seem to recall there is already...

manaclock is not installed by default and is part of manatools package.
In any case you should also probably need gtk3 anyway since:
https://github.com/libyui/libyui-gtk/blob/master/PROJECTINFO.cmake
libyui-gtk is built against it

> well mate is not kde

This is bound to cause some confusion. I'm stuck with two meanings for that:

- Mate DE is not KDE and
- well, dude, it's not KDE

Anyway, this time I'm 100% certain I made sure NTP sync was not asked at installation -- though my timezone was asked and correctly set.

Now, I may need to change time... that's not frequent because since some years ago Daylight Savings Time is correctly adjusted, but e.g. for a publicly displayed KDE clock widget I might need to set the minute exactly.

Bug 11389 was marked as duplicate of this one (though it seems not to be), but it's old and the present one was tested on M5 RC.

Also, following a suggestion in that bug, I tested the time-setting functions in a Konsole after changing to root.

That is, I did:

su - [Enter]
[entered root password]

systemsettings [Enter]

result: cannot set time

Then:

drakclock ; date

As result, drakclock displays the time I chose (in my test 4 hours less). Then date displays the date has returned to correct present time. Something like:

9:01:00
13:01:00

It's like something is syncing time immediately with some external reference.

I found I can use hwclock and set it however I want it (e.g. to another year). Using drakclock, though, resets it to current time.

Renato, as far as i can say you should use timedatectl from console.
systemd-timedated service should be active and that is not managed by drakclock,
if nothing has changed in last months

I mean systemd-timedated is installed and active by default

Ah, thanks, Angelo, for taking the time to explain to me. I'm kind of an old dog and got to learn some new tricks.

I tried to set the time with timedatectl and noticed that NTP syncing was active (so, not possible). It's some kind of service separate from "normal" NTP syncing, since I installed specifically asking NTP not to be active and both KDE and drakclock report that there's no NTP syncing.

Then I used timedatectl to deactivate NTP and then the time could be set (with root authentication, that is). I believe manaclock is planned to do that in a more easy fashion, in the future.

So, as far as I'm concerned, an important need for a desktop was provided and I consider this bug RESOLVED, WORKSFORME. I can wait to have a better interface later or even in M6.

But I'll leave it to Mageia people to close it, because they may want to write a Release Note about KDE and drakclock not working -- and the timedatectl alternative.

For the future, I suggest tweaking the installation process so that people don't think NTP is not active -- that may have some security implications.

Thanks for your patience. Please keep up the good work.

Renato, could you propose a small text that explains all of this so that we can envision adding to release notes? (not errata since it's not a bug?)

Samuel, indeed it is a bug. Drakclock and installer don't consider ntp as active if systemd ntp sync is installed and running and that is installed and activated by default.

Can you rephrase the summary so that it reflects the true cause?

Colin?

Samuel hope this is better :)

(In reply to Angelo Naselli from comment #47)
> Samuel hope this is better :)

yes, thanks :)

Hi, folks! Samuel, sorry for not reading your message before.

Just to have a better idea of it all, I reinstalled M5 RC.

I could notice the same problem exists in all desktops: systemd has an NTP service active but all DEs are none the wiser. I couldn't change the time also using MCC also in IceWM.

The following desktops were tested: KDE, IceWM, Xfce, LXDE and Mate.

Previously to the reinstallation, I had disabled NTP syncing with "timedatectl set-ntp 0" which made possible to change time like explained in comment #42. This caused a smal confusion when I successfully changed time in IceWM and wrongly concluded the problem was KDE only.

Accordingly, I will further abbreviate Angelo's suggestion to convey the idea that the problem exists in other DEs -- not just KDE as I originally wrote when creating this bug. But Angelo's explanation about the bug itself seems accurate.

Thanks.

Thanks Renato. Could you write a small explanation in the Errata page?

Samuel I think bug #15019 is also related.

I think Angelo is right. Bug 15019 is basically the same problem.

BTW, I did some further testing and when drakclock is told to deactivate NTP syncing, it asks chronyd to be installed and that doesn't work... because it does not interact with systemd (apparently).

Samuel and Angelo, I suggest the following two notes in section 3 and 5 of the Errata. What do you think? (alternatively, they can be put in a single note in section 5)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

3.x NTP syncing always activated

At the end of the installation, a summary shows a setting about NTP syncing (click on "Timezone", then Next/Forward).

That is ineffective: NTP syncing is currently activated anyway.

Please see "Setting time" in "Software Issues".

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

5.x Setting time

Because clock synchronization is active by default (more in "Installer Issues","NTP syncing always activated"), setting time is impossible both in Mageia Control Center and in KDE's Time and Date configuration.

A workaround is to turn it off with the command (root authentication needed):

$ timedatectl set-ntp false

Thereafter, MCC and KDE configuration functions will be able to set time and date again.

Please note:

- there may be some delay until panel clocks are updated;
- new time can be verified immediately with "date" or "timedatectl";
- setting a later time may lock the screen, if the screensaver is enabled.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Renato please do, we will review it eventually :)

Done. No intra-Errata links used, though. Maybe after the review... ;-P

Thanks Renato. Don't hesitate to propose other Errata entries for bugs you are involved with and which have the FOR_ERRATA whiteboard marker.

Whiteboard: MGA5TOO FOR_ERRATA => MGA5TOO IN_ERRATA

OK, no problem, I'm glad to help.

Is this bug still valid, btw?

Keywords: (none) => NEEDINFO

(In reply to Marja van Waes from comment #57)
> Is this bug still valid, btw?

Has anything been done to address it?

Keywords: NEEDINFO => (none)

Is systemd-timesyncd disabled during installation? 
manaclock manages also systemd-timesyncd the code is not the same any more since i used systemd-timedated to manage changes as much as possible, but the answer to the question is yes this problem should be hidden otherwise i'd say no since it asks to install chrony if only systemd-timesyncd is in the system.

Moreover, unfortunately you cannot set the ntp server anymore in chrony since configuration file now has pool and not servers.

Our tools and packages should not be configuring systemd-timedated to be used.

why? if it is installed by default... and that is the reason why drakclock does not work in this bug. manaclock just use systemd dbus api so it stops/starts the service and manage correctly the time sync.

It shouldn't be installed by default and if it is we need to fix that.  We just need to fix drakclock to work the way it was intended (prefer chrony but still support ntpd if that's already installed).  systemd-timedated has no advantages over any other implementation.

Also, systemd-timedated is just another wrench in the works that has taken us farther away from getting this working correctly, but it isn't the reason drakclock was broken.  We never correctly finished the transition to chrony by default.

Just tested it on Mageia 5 and Mageia 6 sta 1 and it's still present: cannot set time with CLI (date -s as root) or MCC.

In Mageia 6 specially I made sure the time zone was my own (at the end of installation) and NTP syncing was turned off. Even so, the systemd syncing component was activated and thus prevented any change in time.

David, Thierry what do you think to a quick workaround solution like this, when drakclock is running and NTP is checked we can invoke systemctl systemd-timesyncd stop and disable (if running maybe i need to check if our apis there manage it).
That should work also during installer if I'm not wrong.

But we have two problems in drakclock (that i don't have in manaclock) e.g. NTP seems always disabled (iirc a value was written in a sysconfig file) and we cannot set the source using chrony (that I'm not sure i can port in the drakclock code from manaclock)

Well, just looking outside the black box (that's what I can do since I'm no developer), the following things seem to happen (please correct me where I got it wrong):

1. I *suppose* people adopted systemd because it eases the distribution making process (as compared to previous methods); this ultimately benefits users, so no complaint from me;

2. systemd introduces new ways of doing things; in the present case, it's about NTP syncing;

3. applications which did things the old way (like MCC/drakconf) no longer have an effect on the new system (systemd); it is of utmost importance that this is corrected; here, correction may mean: a) fixing drakconf so that it completely works with systemd; b) abandoning drakconf and using whatever tools systemd provides (that would be ugly); c) creating a new config tool (may be easier than fixing drakconf, to be honest I don't know); as a simple user, I cannot know which of these methods is closer to solve this conundrum;

4. some people really need to avoid NTP syncing (e.g. for security reasons); turned off in the installer, the nonetheless active syncing means the installer is not controlling systemd (which is analogous to the drakconf problem and also needs to be addressed);

5. finally, KDE (& others) also should be able to deactivate systemd NTP syncing (for that is a normal DE functionality).

A temporary (and maybe faster) solution would be creating a tool to enable the control of systemd-timesyncd while being capable of interacting with the traditional tools (drakconf, KDE's time and date module etc.), much like one can still use "ifconfig" even after the change to "ip" commands.

It must be said that any change, however necessary, brings a period of turmoil. Mageia has now entered a phase in which it must create new things and cannot just rely on the excellent foundations from which it grew.

Sorry for the digression.

Well manaclock is a big part of a solution to what you say, it does not cover the installer only.

My comment was not so much about the ongoing improvements, but more like a "keep up the good work" post. Thank you, Angelo, BTW, for your efforts and also extensive to everyone who makes Mageia one the best distributions there is.

Hey, I noticed it was fixed in one of my tests machine (I'm testing M6 in two, in fact). The other still has the problem...

Thank you.

So systemd-timesyncd shouldn't be getting enabled by default anymore, so that's progress.  Angelo, yes I think it would be good if drakclock would disable it if it happens to be enabled, that would probably help a little (it's currently not aware of it at all).

As far as what KDE or other DE's own NTP settings modules might do, I'm not sure there's much we can do about that.

No we just have to fix systemd not to enable things we do not want.
WHich is done for systemd-timesyncd

So this one should be fixed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED
Source RPM: kdebase4-workspace => kdebase4-workspace, systemd

No, we patched it! I think that should be done by upstream. 

But i agree we should not enable (or disable if they are) things that we don't want, then we can discover that we, are not everybody as we can see in bug#19113.