On Thursday 2011-03-31 07:53, Damyan Ivanov wrote: >> >>>Not sure if it matters, but the hardware clock is using UTC (i.e. >>>/etc/default/rcS contains "UTC=yes"). >> >>When the xt_time kernel module is loaded, it prints the current timezone >>the kernel is operating with - and this is what xt_time will be using >>when doing localtz comparisons. > >Thanks for the reply. > >Indeed, there is this message in dmesg: > > xt_time: kernel timezone is -0000 >
I too use UTC, but I don't get 0000. /etc/sysconfig# head -n10 clock; hwclock; date; rmmod xt_time; modprobe xt_time; dmesg | tail -n1; ## Path: System/Environment/Clock ## Description: Information about your timezone and time ## Type: string(-u,--utc,--localtime) ## ServiceRestart: boot.clock ## Command: /sbin/refresh_initrd # # Set to "-u" if your system clock is set to UTC, and to "--localtime" # if your clock runs that way. # HWCLOCK="-u" Thu Mar 31 12:16:01 2011 -0.767810 seconds Thu Mar 31 12:16:03 CEST 2011 [383639.470885] xt_time: kernel timezone is +0100 # cat /etc/SuSE-release openSUSE 11.4 (x86_64) I think there is no bug here currently - the Linux system was written such that each user could have his own TZ setting applied to shells, desktop, etc. (Which requires that the kernel always keeps an UTC clock somewhere.) On boot, once the kernel UTC clock has been initialized from the RTC + $(DST result of "date" command), the KTZ is independent, much like just another user's environment variable. >I have set the hardware clock to use the local timezone and it changed >to > > xt_time: kernel timezone is +0300 > >It seems to fix the problem, but I wonder what would happen at the >next DST change. I guess it would require to shut down the firewall, The particular box I have shown output from still reads +0100 while 4 days ago, DST began and thus would have become +0200. Since the KTZ is set by distro scripts once at boot, one can't blame ntpd for not updating the KTZ. After all, ntpd only needs to concern itself with adjusting the UTC clock, since timezones is not a system property, but per-user. Given these findings, the localtz option is obviously heavily dependent on KTZ, and maybe should be ripped out of the xt_time module to avoid surprises. >reload xt_time and restart the firewall so that it picks up the >correct timezone (If the kernel changes its at all. I have never used >UTC=no before). Still a suboptimal solution? Reloading xt_time won't change anything. Someone or something would need to set the KTZ, and once it does so, xt_time will pick it up automatically. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
