Bug 773491

Well, if the timezone is correctly set to London (and it seems to be, based on the output of "date"), then it's a bug in YaST.

Note that the GNOME system settings simply use the timedated API from systemd to set the timezone.

My guess is that YaST relies on some field in sysconfig and blindly trusts it, while it shouldn't.

(In reply to comment #1)

> My guess is that YaST relies on some field in sysconfig and blindly trusts it,
> while it shouldn't.

Indeed. But so far, nobody complained.

How exactly does GNOME system settings recognize (and save) current time zone?


For example with the 'date +%Z', I get correct offset, but not the exact timezone as saved by YaST. Does GNOME make a symlink of /etc/localtime, so I can see where is it pointing to?

As I said, GNOME is using timedated from systemd: http://cgit.freedesktop.org/systemd/systemd/tree/src/timedate/timedated.c

There's a property to get the timezone and a method to set the timezone (which, in summary, will run write_data_timezone() function).

Seems like write function uses symlink.

So, question for Bin Li:

- what is the content of your /etc/timezone?
- is your /etc/localtime symbolic link, and if so, where does it point to? (I'm hoping that it should point to /usr/share/zoneinfo/Europe/London)

(In reply to comment #4)
> Seems like write function uses symlink.
> 
> So, question for Bin Li:
> 
> - what is the content of your /etc/timezone?
This file doesn't exist.

> - is your /etc/localtime symbolic link, and if so, where does it point to? (I'm
> hoping that it should point to /usr/share/zoneinfo/Europe/London)

$ l /etc/localtime 
-rw-r--r-- 5 root root 311 Jul 25 22:41 /etc/localtime

It's not a symbolic link.

Jiri,

Now I'm in Beijing, and I change the Timezone to Beijing in Yast. But the timezone in 'System Settings' still in 'Europe/London'

And I check the /etc/sysconfig/clock, it display like below.

TIMEZONE="Asia/Beijing"
DEFAULT_TIMEZONE="US/Eastern"

After view the commment, /etc/localtime shoud be updated by Yast, but when I change the timezone to 'Asia/Beijing', the /etc/localtime isn't changed.

## Type:                string(Europe/Berlin,Europe/London,Europe/Paris)
## ServiceRestart:      boot.clock
## Command:             /sbin/refresh_initrd
#
# Timezone (e.g. CET or Asia/Tokyo). The value should correspond
# to the contents of the /etc/localtime file and is for internal
# YaST use; changing this setting will not make SuSEconfig update
# the /etc/localtime file, YaST does that or you will need to do
# this manually by calling zic -l.
#
TIMEZONE="Asia/Beijing"
DEFAULT_TIMEZONE="US/Eastern"

(In reply to comment #6)

> > - what is the content of your /etc/timezone?
> This file doesn't exist.


Strange. Vincent, are you maintainer of this part of systemd? Or Frederic, are you?

write_data_timezone from timedated.c should write /etc/timezone, right? The read function seems to rely on it, so why wasn't it written?


And another part:

(In reply to comment #7)

> Now I'm in Beijing, and I change the Timezone to Beijing in Yast. But the
> timezone in 'System Settings' still in 'Europe/London'

YaST adapts sysconfig value AND /etc/localtime as well. Why System settings does not read it correctly?

After I delete the /etc/localtime, then change the time in Yast, the /etc/localtime was up, looks like copy from somewhere cause the file time is very old.

l /etc/localtime 
-rw-r--r-- 5 root root 311 Jul 25 22:41 /etc/localtime

(In reply to comment #9)
> (In reply to comment #6)
> 
> > > - what is the content of your /etc/timezone?
> > This file doesn't exist.
> 
> 
> Strange. Vincent, are you maintainer of this part of systemd? Or Frederic, are
> you?

I'm not, I guess it's Frédéric then.

> write_data_timezone from timedated.c should write /etc/timezone, right? The
> read function seems to rely on it, so why wasn't it written?

Not sure, it should write it, indeed.

> And another part:
> 
> (In reply to comment #7)
> 
> > Now I'm in Beijing, and I change the Timezone to Beijing in Yast. But the
> > timezone in 'System Settings' still in 'Europe/London'
> 
> YaST adapts sysconfig value AND /etc/localtime as well. Why System settings
> does not read it correctly?

The GNOME tools just fetch the timezone from timedated. And timedated apparently only reads /etc/timezone (see the read_data function() from http://cgit.freedesktop.org/systemd/systemd/tree/src/timedate/timedated.c)

(In reply to comment #11)

> > > Now I'm in Beijing, and I change the Timezone to Beijing in Yast. But the
> > > timezone in 'System Settings' still in 'Europe/London'
> > 
> > YaST adapts sysconfig value AND /etc/localtime as well. Why System settings
> > does not read it correctly?
> 
> The GNOME tools just fetch the timezone from timedated. And timedated
> apparently only reads /etc/timezone (see the read_data function() from
> http://cgit.freedesktop.org/systemd/systemd/tree/src/timedate/timedated.c)

Yes, I've seen this. But is /etc/timezone mandatory? YaST does not save it and time setting works correctly for years...

The GNOME tool is broken.  There is only *ONE* location where the system time zone is defined: /etc/localtime.  This is used by all glibc functions and define the user space local time and therefore also the timezone as the system clock of the kernel is in UTC.

@Frederic? Why does Lennart provide with timedated a second way to determine the timezone.  IMHO this is broken, the system timezone is given in  /etc/localtime and the glibc API provides all required tools to determine this, e.g.:

     date +'%z'

just uses glibc API and therefore /etc/localtime or if the user uses the TZ variable the users personal timezone.

Please could you enforce the systemd people not to use a second location for the system timezone?

/etc/timezone is coming from Debian (and was added in systemd for compatibility with Debian, as seen in timezone(5) manpage).

There has been discussing upstream recently (this month) to drop /etc/timezone and use /etc/localtime instead (see the thread at http://lists.freedesktop.org/archives/systemd-devel/2012-August/006144.html ).

I'll cook a package with the patches doing that (I expect them to be merged upstream pretty soon).

Ahh OK ... now that are good news :)

Good that systemd will get better, but for YaST, I would like to know what to expect. If /etc/sysconfig/clock value is not correctly filled, what should I read?

Could I expect /etc/localtime is a symlink? Than I could find out current timezone simply.

Should I check /etc/timezone at all? (= will systemd write this file? Patch in previous comment does not mention writing)

I suggest to forget about /etc/timezone: it will go away sooner or later, so it isn't worth implementing support in YaST for it.

Currently /etc/sysconfig/clock is not read at all by systemd (since we aren't on Fedora). I could adapt systemd so it could parse /etc/sysconfig/clock in "SUSE" format, as a fallback.

The proposed upstream patch to support /etc/localtime is expecting /etc/localtime to be a symlink to a zoneinfo file in /usr/share/zoneinfo, which isn't the case (probably because it wouldn't work with /usr on a separate partition, when mounting /usr was not done in initrd). And the code proposed relies on the symlink information to guess the timezone name. So, it might be better to switch to symlink when it is modified by YaST (and if I add support for /etc/sysconfig/clock in SUSE format, timedated will be able to guess the timezone name when /etc/localtime is a file and will replace it with a symlink when timezone is modified).

Unless there is a way to get the timezone date from the /etc/localtime content itself. Werner, any idea ?

(In reply to comment #17)
> ...  And the code proposed
> relies on the symlink information to guess the timezone name. So, it might be
> better to switch to symlink when it is modified by YaST

YaST does not modify the file directly, but calls zic. I think zic copies /etc/localtime file, does not symlink it.

(In reply to comment #18)
> (In reply to comment #17)
> > ...  And the code proposed
> > relies on the symlink information to guess the timezone name. So, it might be
> > better to switch to symlink when it is modified by YaST
> 
> YaST does not modify the file directly, but calls zic. I think zic copies
> /etc/localtime file, does not symlink it.

This is from a patch we added in 2010 (timezone package):

Tue Aug 24 12:11:51 CEST 2010 - pbaudis@suse.cz

- Make zic -l do a copy when hardlinking fails (e.g. because /usr
  being on a separate partition) [bnc#607532]

I'm pretty sure we can drop it, since /usr is now mounted in initrd.

(In reply to comment #17)

To determine the timezone you may use

   TZ=/etc/localtime date +'%Z with %z'

on the other hand this does not show the real timezone file
with some bash code it should be easy to find the file

   md5=($(md5sum /etc/localtime))
   for f in $(find /usr/share/zoneinfo/ -type f); do
       set -- $(md5sum $f)
       test $md5 = $1 && break
   fi
   echo $f

...

(In reply to comment #19)

No apply is OK but drop before the SLES12 is out there we should not do as we may fall back if some big vendors insist on a separate /usr parition ... and
just for the case of doing an update fdrom SLES11 to SLES12 with an existing
/usr parition

(In reply to comment #20)

> on the other hand this does not show the real timezone file
> with some bash code it should be easy to find the file
> 
>    md5=($(md5sum /etc/localtime))
>    for f in $(find /usr/share/zoneinfo/ -type f); do
>        set -- $(md5sum $f)
>        test $md5 = $1 && break
>    fi
>    echo $f

Several files under /usr/share/zoneinfo/ have same md5 sum. This explains why, after I chose Europe/Prague in (this time KDE) destktop tool, it showed me Europe/Bratislava next time.

Although the time is correct, I still think it is not correct behavior.

(In reply to comment #22)

I'm aware that this is not biunique as a zone file with different names
may contain the same timezone *and* the same rules.

(In reply to comment #21)
> (In reply to comment #19)
> 
> No apply is OK but drop before the SLES12 is out there we should not do as we
> may fall back if some big vendors insist on a separate /usr parition ... and
> just for the case of doing an update fdrom SLES11 to SLES12 with an existing
> /usr parition

Well, since we still support /usr on a separate partition (it is handled in
initrd and not at the initial boot), it could continue to work as expected.

What we can do is no longer apply the patch, starting with openSUSE 12.2. 

> (In reply to comment #22)
> (In reply to comment #20)
> 
> > on the other hand this does not show the real timezone file
> > with some bash code it should be easy to find the file
> > 
> >    md5=($(md5sum /etc/localtime))
> >    for f in $(find /usr/share/zoneinfo/ -type f); do
> >        set -- $(md5sum $f)
> >        test $md5 = $1 && break
> >    fi
> >    echo $f
> 
> Several files under /usr/share/zoneinfo/ have same md5 sum. This explains why,
> after I chose Europe/Prague in (this time KDE) destktop tool, it showed me
> Europe/Bratislava next time.
> 
> Although the time is correct, I still think it is not correct behavior.

Then we need to keep the name of the timezone somewhere. Either in
/etc/sysconfig/clock or as part of the symlink name for /etc/localtime

(In reply to comment #24)

Hmmm ... if we support separate /usr then hadlinks are a nogo.

(In reply to comment #25)
> (In reply to comment #24)
> 
> Hmmm ... if we support separate /usr then hadlinks are a nogo.

agreed, better to use symlink and rely on /usr being mounted by initrd (not for SLE11, of course, where we should stick to copying the file).

I've pushed to home:fcrozat:branches:Base:System systemd a patched version of systemd which does the following: 
- understand /etc/localtime as a symlink to a zoneinfo file to detect the zoneinfo name, otherwise, fallback to /etc/sysconfig/clock, TIMEZONE variable value
- when setting a timezone with timedated, /etc/timezone is removed and /etc/localtime is replaced by a symlink to the zoneinfo file. /etc/sysconfig/clock is not modified
- all suppport for /etc/timezone is removed (we never supported that and better to not start doing so).

I'd suggest we modify zic to create a symlink, starting with openSUSE 12.2 and to modify YaST to use the symlink value of /etc/localtime (when it exists) as the "reference" value for timezone (/etc/sysconfig/clock would only be used as fallback and deprecated in the future).

I've submited new yast2-country to Factory:

created request id 131009


Who is going to adapt zic according to comment 27? Werner?

From my point of view the maintainer of the corresponding package

  > rpm -qf /usr/sbin/zic
  timezone-2009d-0.1
  > maintainer timezone
  bugowner of Base:System/timezone -- pbaudis@novell.com

welcome Petr :)

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/131009 Factory / yast2-country

I've patched zic to use symlink by default (when compiled on 12.2 or later) and not apply the old "copy" patch on 12.2 or later.

Package is available on home:fcrozat:branches:Base:System / timezone.

I've also updated systemd in home:fcrozat:branches:Base:System with new version of locatime patch from original author which is handled symlink created by zic correctly now.

the integration isn't perfect yet: when updating timezone in yast, timedated isn't aware of the change, if it was running before (not sure how to fix that properly, apart from restarting timedated using systemctl try-restart systemd-timedated.service)

(In reply to comment #32)

> the integration isn't perfect yet: when updating timezone in yast, timedated
> isn't aware of the change, if it was running before (not sure how to fix that
> properly, apart from restarting timedated using systemctl try-restart
> systemd-timedated.service)

You mean when zic is called from YaST? 

Should YaST do anything here?

(In reply to comment #33)

Sounds like a job for an inotfiy watch on /etc or /etc/localtime, in last case
the watch has to restarted in case of changing the symlink.

(In reply to comment #33)
> (In reply to comment #32)
> 
> > the integration isn't perfect yet: when updating timezone in yast, timedated
> > isn't aware of the change, if it was running before (not sure how to fix that
> > properly, apart from restarting timedated using systemctl try-restart
> > systemd-timedated.service)
> 
> You mean when zic is called from YaST? 

yes, because /etc/localtime is updated without systemd-timedated being aware of the change (if it was running, which isn't the case most of the time)

>
> Should YaST do anything here?

I suggest adding a non-fatal call to "systemctl try-restart systemd-timedated.service"



(In reply to comment #34)
> (In reply to comment #33)
> 
> Sounds like a job for an inotfiy watch on /etc or /etc/localtime, in last case
> the watch has to restarted in case of changing the symlink.

But I'm not sure upstream will merge such patch, since they probably expect applications to use the D-Bus interface to access this file (with added benefits of D-Bus change event of other applications listening for it). I'll ask them.

(In reply to comment #35)

> > Should YaST do anything here?
> 
> I suggest adding a non-fatal call to "systemctl try-restart
> systemd-timedated.service"

OK, I'll add it just after the zic call.

diff --git a/timezone/src/Timezone.ycp b/timezone/src/Timezone.ycp
index 2374120..e8bb3bf 100644
--- a/timezone/src/Timezone.ycp
+++ b/timezone/src/Timezone.ycp
@@ -282,6 +282,9 @@ global define integer Set (string zone, boolean really) {
        string cmd = "/usr/sbin/zic -l " + timezone;
        y2milestone( "Set cmd %1", cmd );
        y2milestone( "Set ret %1", SCR::Execute( .target.bash_output, cmd ));
+        cmd     = "/bin/systemctl try-restart systemd-timedated.service";
+        y2milestone ("restarting timedated service: %1",
+            SCR::Execute (.target.bash_output, cmd));
        if (!Arch::s390 ())
        {
            cmd = "/sbin/hwclock --hctosys " + hwclock;

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/131298 Factory / yast2-country

I hope we can close it now

We still need timezone and systemd to be pushed to Base:System (and then to Factory / 12.2).

I have done the sr yet, waiting for feedback, but got none so far..

(In reply to comment #40)

> I have done the sr yet, waiting for feedback, but got none so far..

Should the reported test your packages?

Yes and people should also check my zic patch. I've tested those packages myself and they work fine but better to have second opinions.

PS: I'll be off for 3 weeks starting Friday evening, so if you want me to sr those packages, it better to be soon.

sr 131520 for systemd part and sr 131519 for timezone

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/131610 Factory / systemd
https://build.opensuse.org/request/show/131611 Factory / timezone

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/131619 Factory / timezone

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/131930 Factory / yast2-country

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/134186 Factory / timezone
https://build.opensuse.org/request/show/134187 Factory / timezone

openSUSE-RU-2012:1255-1: An update that has three recommended fixes can now be installed.

Category: recommended (low)
Bug References: 773491,774918,780206
CVE References: 
Sources used:
openSUSE 12.2 (src):    yast2-country-2.22.10-2.4.1

openSUSE-RU-2012:1276-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 762210,773491,780276
CVE References: 
Sources used:
openSUSE 12.2 (src):    timezone-2012f-1.4.1, timezone-java-2012f-1.4.1
openSUSE 12.1 (src):    timezone-2012f-1.6.1, timezone-java-2012f-1.6.1
openSUSE 11.4 (src):    timezone-2012f-6.1

Cause it was in progress updating, I thought we could close this one.

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/159286 Evergreen:11.2 / timezone

I guess this is still open since the systemd patches don't seem to have made it into 12.2? (This is no longer apparent from GNOME Control Center, which was patched to not use timedated, rendering this Not A Big Deal.)

I kind-of forgot about the systemd patch for 12.2

Is it really needed ? I have some patches which are in a pending update for 12.2 so I could add it and push everything.

(In reply to comment #55)
> I kind-of forgot about the systemd patch for 12.2
> 
> Is it really needed ?
I doubt it's needed; I don't know who all consumes timedated in 12.2, but I'm only aware of gnome-control-center and timedatectl.  timedatectl is still royally broken, but it will be even with this patch (Bug #803644), and it's not like timedatectl is the first thing I'm going to try when I want to change my timezone.

let's close as fixed, then.

This is an autogenerated message for OBS integration:
This bug (773491) was mentioned in
https://build.opensuse.org/request/show/175978 Evergreen:11.2 / timezone