Daylight-saving-time to solar-time switch failure [Solved]

Discussions Regarding Software

Moderator: Moderators

thenthenio
Old Dear Hen
Posts: 522
Joined: Thu Mar 01, 2007 23:11
Location: Melegnano (MI) Italy

Daylight-saving-time to solar-time switch failure [Solved]

Post by thenthenio » Mon Oct 27, 2008 12:18

Hello everybody.
On my 2 PCs with SL3.5 (alone) the (supposed) automatic switch failed.
The configuration is exactly the same:
The BIOS saved time is Rome (Central Europe Time):
# hwclock
lun 27 ott 2008 13:08:20 CET -0.136396 secondi
Opening Modify date and time (selecting from the context menu right-clocking on the clock) I can see that the Timezone is correct: Rome (CET) and Set date and time automatically is checked, so the time should adjust automatically using the NTP server specified on the drop-doown menu on the right (which is pool.ntp.org).
Despite this on both PCs the time did not adjusted automatically.
To get the time updated I manually unchecked and checked again the Set date and time automatically checkbox.
Does somebody knows why thid did not happen automatically?

Thanks.
Mauro

Fitzcarraldo
Sagely Hen
Posts: 8200
Joined: Sat Mar 10, 2007 5:40
Location: United Kingdom
Contact:

Re: Daylight-saving-time to solar-time switch failure

Post by Fitzcarraldo » Mon Oct 27, 2008 12:36

The BIOS (hardware) clock is only updated when you shutdown and if you have the entry clock_systohc="YES" in the file /etc/conf.d/hwclock. Do you have that entry, Mauro? Also, the BIOS clock, as opposed to the system clock, will only be updated to the new time once you shutdown following the adjustment of the system time. What is the polling time of the NTP client on your PC? Was the PC on for a long time and the system clock still did not update?

thenthenio
Old Dear Hen
Posts: 522
Joined: Thu Mar 01, 2007 23:11
Location: Melegnano (MI) Italy

Re: Daylight-saving-time to solar-time switch failure

Post by thenthenio » Mon Oct 27, 2008 13:52

Hello Fitz!
The setting was:
clock_systohc="NO"
I don't know how to set the polling time to the NTP server.
Maybe it is so long that it never happened on last Sunday, or maybe it is updated via crond and tha update time was not during the upptime...
If the setting here is "do not save the system clock to the BIOS", wouldn't be a good thing to synchronize to NTP server during boot process instead of waiting some scheduled time or period?

Cheers.
Mauro

Fitzcarraldo
Sagely Hen
Posts: 8200
Joined: Sat Mar 10, 2007 5:40
Location: United Kingdom
Contact:

Re: Daylight-saving-time to solar-time switch failure

Post by Fitzcarraldo » Tue Oct 28, 2008 13:52

The first thing you need to do is make it "YES" so that your hardware clock is updated to the correct time from the system clock each time you shut down your PC. The hardware clock drifts over time and, if you are synchronising your system clock from time to time (either manually or via NTP) then it will be more accurate than the hardware clock.

Also, did you also perform the command mentioned in the Wiki article to have the correct localtime file? For example, if you live in Italy you would enter:

Code: Select all

cp /usr/share/zoneinfo/Europe/Rome /etc/localtime
The permissible zoneinfo for Europe are:

Code: Select all

localhost Europe # pwd
/usr/share/zoneinfo/Europe
localhost Europe # ls
Amsterdam   Chisinau     Kiev        Moscow      Sarajevo    Vatican
Andorra     Copenhagen   Lisbon      Nicosia     Simferopol  Vienna
Athens      Dublin       Ljubljana   Oslo        Skopje      Vilnius
Belfast     Gibraltar    London      Paris       Sofia       Volgograd
Belgrade    Guernsey     Luxembourg  Podgorica   Stockholm   Warsaw
Berlin      Helsinki     Madrid      Prague      Tallinn     Zagreb
Bratislava  Isle_of_Man  Malta       Riga        Tirane      Zaporozhye
Brussels    Istanbul     Mariehamn   Rome        Tiraspol    Zurich
Bucharest   Jersey       Minsk       Samara      Uzhgorod
Budapest    Kaliningrad  Monaco      San_Marino  Vaduz
localhost Europe #  
If the ntp-client is not already started at boot on your PC and you want to set your system clock time via NTP on every boot (assuming your PC is always connected to a network with access to an NTP server) then see item 3.4 on the following Web page:
http://linuxreviews.org/howtos/ntp/

If you want to run ntp-client NOW, just enter the command:

Code: Select all

/etc/init.d/ntp-client start
If you have set up /etc/conf.d/ntp-client incorrectly and, on your next boot-up you are left in console mode, log in as root and enter:

Code: Select all

rc-update delete ntp-client
and then you can reboot as normal and fix things.

thenthenio
Old Dear Hen
Posts: 522
Joined: Thu Mar 01, 2007 23:11
Location: Melegnano (MI) Italy

Re: Daylight-saving-time to solar-time switch failure

Post by thenthenio » Tue Oct 28, 2008 22:57

Thank you Fitzcarraldo!
In 3.4F it was going crazy, absolutely unpredictable.
On 3.5 some time ago I was having troubles with local and UTC time.
Now that it was ok the synchronization was lost upon changing from daylight saving to solar time...
I hope now it's finished!
What I do not understand is what the KDE damn settings stand for if they are completely ignored?
I'm pretty sure that apart from the changing of the time (from daylight saving to solar) that I never tested, in Kubuntu the KDE settings worked and the clock never gave any problem.

Ciao.
Mauro

Fitzcarraldo
Sagely Hen
Posts: 8200
Joined: Sat Mar 10, 2007 5:40
Location: United Kingdom
Contact:

Re: Daylight-saving-time to solar-time switch failure

Post by Fitzcarraldo » Wed Oct 29, 2008 11:21

If you have any trouble at boot-up because ntp-client is running before your PC connects to the network, then, instead of adding ntp-client to the default run level, try putting the ntp-client start command (or, alternatively, the ntpdate -b -s -u <server> command) in /etc/conf.d/local file instead (put it inside the curly brackets of local_start). BTW, you could instead run ntpdate manually at any time or set up a crontab to run it periodically. Actually there are various alternative ways of synchronising the system clock via NTP, including several I've not mentioned, and you can read about the various methods via a bit of googling. I used to have the ntp daemon running but have not bothered in my latest couple of installations as my laptop is often not connected to a network. Perhaps when SL 4.0 is released and I install it, then I'll also set up ntpd or ntp-client or ntpdate or rdate or whatever to resync the system clock from an NTP server on the Net. But, irrespective of whether or not one synchronizes one's system clock to an external time server, one should do everything mentioned in the SL Wiki article to make sure that one's local timezone is set up correctly. Maybe I need to reword the article a bit, because it seems most people who read it think it only applies if you dual boot with Windows; in fact it is equally relevant even if one only has SL or Gentoo installed.

thenthenio
Old Dear Hen
Posts: 522
Joined: Thu Mar 01, 2007 23:11
Location: Melegnano (MI) Italy

Re: Daylight-saving-time to solar-time switch failure

Post by thenthenio » Wed Oct 29, 2008 15:41

Ciao Fitz, thank you again for the help.
Actually everything looks fine.
I had no problems with boot and system clock and hw clock agree!
Obviously for the next change from solar time to daylight saving I have to wait almost 6 months (I cannot fool the NTP client).

Ciao,
Mauro

thenthenio
Old Dear Hen
Posts: 522
Joined: Thu Mar 01, 2007 23:11
Location: Melegnano (MI) Italy

Re: Daylight-saving-time to solar-time switch failure

Post by thenthenio » Wed Oct 29, 2008 23:01

I was too much optimistic...
Sometimes ntp-client service starts at boot, sometimes not.
When it does not start the display remains in first virtual console, but X (kdm) is running, it simply does not switch to VT7!
This happens on both my SL3.5 x86_64 PCs.
I know I can probably fix it moving the startup in /etc/conf.d/local but I would like to understand why the behavior is not deterministic.
Both PCs have 24/7 wired connection to the Internet (via local network DHCP router to ADSL line)

Any ideas?
Mauro

Fitzcarraldo
Sagely Hen
Posts: 8200
Joined: Sat Mar 10, 2007 5:40
Location: United Kingdom
Contact:

Re: Daylight-saving-time to solar-time switch failure

Post by Fitzcarraldo » Thu Oct 30, 2008 12:35

Well, I'm not sure, to be honest, but my guess would be that start-up is not completely deterministic when a group of tasks is launched virtually simultaneously (i.e. within microseconds or milliseconds of each other), because the network will not always take exactly the same time to react on each boot. As a rough analogy, if you ping a node on your home network or on the Net (say, for example, an NTP server), the node will not respond with exactly the same delay every time. Just ping e.g. http://www.google.com and the reply does not take exactly the same number of milliseconds each time. Someone with detailed knowledge of the Linux start-up process (both inter run level and intra run level) would have to confirm this, but my guess is that, although run levels in Linux do run in sequence, within each run level various tasks are kicked off but the OS does not necessarily wait for each task to run or reach a certain state before kicking off the next one unless the user configures it that way. Presumably the init process is not checking if the network daemon (or whatever) is up and running and connected to the network before launching ntp-client, and sometimes it is up and running in time but at other times it isn't. I suppose it's a bit like the difference between firing the starting pistol for a normal race and firing the starting pistol for a two-stage relay race: in the former everyone tries to start at (more or less) the same time; in the latter the second member of each relay team can only start running when the first member of the team hands over the baton. In this particular case it would be good for ntp-client to be the second member of the relay team. Do you follow what I'm trying to say? I know that certain "services" (I'm not sure what the precise definition of "service" is in this context) in a run level can be made to wait until net.eth0 AND/OR net.eth1 are up, if the user configures /etc/rc.conf accordingly, but I'm not sure if this is relevant when we are speaking about ntp-client specifically. You could also try setting rc_logger to "YES" in /etc/rc.conf to log the entire rc process so as to try and see what is getting kicked off and when. It's also possible to configure /etc/rc.conf (or, I believe, /etc/conf.d/ntp-client instead) to define additional dependencies, so my guess is that it would be possible in /etc/rc.conf or /etc/conf.d/ntp-client to specify "don't start ntp-client until the network is up and running". Maybe it would be as simple as putting the line rc_after="net.eth0" (rc_before?) or something like that in /etc/conf.d/ntp-client. You could try it to see. I would have a go but I'm away from home at the moment and don't have much time to play around. The 'lazy' way I suggested of kicking off ntp-client or ntpdate in /etc/conf.d/local is because, as far as I know, that is kicked off significantly later than tasks such as the networking daemon and so virtually guarantees that the network will be accessible.

thenthenio
Old Dear Hen
Posts: 522
Joined: Thu Mar 01, 2007 23:11
Location: Melegnano (MI) Italy

Re: Daylight-saving-time to solar-time switch failure

Post by thenthenio » Thu Oct 30, 2008 23:56

I understand what you say about non deterministic behavior.
Unfortunately I was again wrong saying that, actually ntp-client never starts, it started only the first 2 boots, then after always failed, so behavior is absolutely deterministic.
What I do not understand now is why it succeeded the first 2 times!
It looks like that network takes a very long time to come up.
But this happens on both SL3.5 x86_64 PCs. a desktop which is at home and a laptop which usually is in the office and obviously DHCP and ADSL routes are completely different the one from the other.
Both PCs had the first 2 boot successful and then failing!
I already notice that on the laptop where I have some Samba file systems that I would like to have automatically mounted at boot and, instead, I have to mount them manually after logging in KDE.
It looks like that network comes up just before opening the KDE session, which I think it's really late.
I think that before running X network should be up and running and all network file systems already mounted...
I will do some testing.

Mauro

Post Reply