time during boot WRONG - GMT???

rholme · #1 22nd March 2012, 11:05 PM

I live in the Eastern US so my normal time zone is GMT +5, now on daylight savings so +4.

I have been having problems with httpd coming up from a script running in /etc/rc.d/rc.local.

The script runs but httpd does NOT start as it should.

In the process I have had a time stamp added to the script.

WHEN THE MACHINE BOOTS, IT BELIEVES IT IS ON GMT, BUT THEN IT FIGURES IT OUT.

I am not sure if this is part of the httpd problem, but it sure is weird.

The result of my "echo..... >>" command looks like:

/local/bin/S92httpd called with start at Thu Mar 22 17:51:09 EDT 2012
/local/bin/S92httpd called with start at Thu Mar 22 13:52:49 EDT 2012

I had just run the script a 5:21 manually; then rebooted getting the 4 hour earlier GMT time (showind as EDT)..

Is this behavior normal or is this some kind of fisable bug.

Iron_Mike · #2 22nd March 2012, 11:34 PM

Did you happen to select the NTP (Network Time Protocol) when you installed Fedora? If you did check it under "system settings" and try turning it off to see if it fixes the issue...

rholme · #3 23rd March 2012, 01:00 PM

OK, that was it. Thanks. But for the record, changing this was not under system-settings - rather administratioin -> system-config-date. PS - it did not fix the httpd problem but at least the date is right. I can add a crontab entry to fix the date once in a while.

Thanks - weird.

---------- Post added at 08:00 AM ---------- Previous post was at 07:35 AM ----------

Well, I guess I spoke out of turn. /usr/sbin/ntpdate and ntpd are no longer there in fedora 16. I see rdate is but I tried 4 suggested servers for rdate (from google searches) - none respond. That is a shame. I will set my clock manually occasionally.

jpollard · #4 23rd March 2012, 01:11 PM

The time zone setting doesn't get synchronized properly with httpd by systemd.

There may be no way to fix that. The TZ setting is supposed to be inherited by all processes that are started following... Unfortunately, systemd does not do that.

You MIGHT be able to kluge it by manually setting the TZ environment variable in the httpd script (before httpd server starts), or possibly by setting it in the "functions" script invoked by all the init.d scripts.

***DBelton*** · #5 23rd March 2012, 02:37 PM

Quote:

Originally Posted by rholme

OK, that was it. Thanks. But for the record, changing this was not under system-settings - rather administratioin -> system-config-date. PS - it did not fix the httpd problem but at least the date is right. I can add a crontab entry to fix the date once in a while.

Thanks - weird.

---------- Post added at 08:00 AM ---------- Previous post was at 07:35 AM ----------

Well, I guess I spoke out of turn. /usr/sbin/ntpdate and ntpd are no longer there in fedora 16. I see rdate is but I tried 4 suggested servers for rdate (from google searches) - none respond. That is a shame. I will set my clock manually occasionally.

Fedora 16 switched to using chrony instead of ntpdate or ntpd. If you check the box in your time/date settings and set network time on, then it should update your clock on each boot, and on a regular interval while the system is running.

rholme · #6 23rd March 2012, 02:49 PM

Yep, but if I do that - the time is wrong until the machine is booted. See original post. Thanks anyway.

My problem with rdate as an alternative is opening up port 37 on my external firewall. I guess I need a new router - until I get one nothing can be changed.

PabloTwo · #7 23rd March 2012, 02:54 PM

It sounds to me like perhaps your hardware clock (the one on the motherboard and kept alive by CMOS backup battery) is set to UTC. You can check it this way.

Code:

date
sudo hwclock --show

The "date" command displays your "system" time, which is probably your local time. If you find that your hardware clock is on UTC and you would like to set it to your local time, you could do it this way.

Code:

yum install ntpdate
ntpdate us.pool.ntp.org
hwclock --systohc

Running the ntpdate command just sets your system time to the correct time, before running the hwclock command to set the hardware clock to the same time as the system time. I just went through this procedure yesterday on my lappy which I boot into runlevel 3, and noticed "date" command was about an hour behind (must have missed the time change to Daylight Savings). I corrected the time with the ntpdate command and thought that was fixed. On my next boot, the date command was still an hour behind. That's when I learned about using the hwclock command. Now my lappy boots to the correct time in runlevel 3.

***DBelton*** · #8 23rd March 2012, 03:08 PM

hwclock used to run on each shutdown to write the system clock back to the hardware clock, but I noticed that one of the systemd updates changed that. This was due to the change to using chrony, I believe. Chrony keeps it's own drift and slew data, and synching the clock back on every shutdown makes that data wrong.

Now, to me, it would be better to sync it back to the hardware clock on shutdown and reset the drift data, but chrony was more designed for machines that are up for months at a time, I believe.

hwclock does run on each boot to set the system clock from the hardware clock, and any other apps like ntpd or chrony need to run after hwclock is run. Chrony, when started takes the system clock, that was just loaded from the hwclock, applies its drift/slew data to correct the time and then goes on about it's business, occasionally checking the time from ntp servers to update it's data and making corrections as needed.

And yes, I got bit by the same thing a few months back when somehow my hardware clock got exactly 12 hours off. Chrony hid the problem, making it harder for me to figure out. I kept getting errors on boot that the timestamp on my filesystem was in the future because the filesystem check ran before chrony adjusted my time back to being correct. Running the command pablotwo stated above reset my hardware clock to being correct, and no errors after that.

rholme · #9 23rd March 2012, 03:24 PM

hmmmm - I yum installed ntpdate and now run it in the crontab once a week. the hwclock --show command shows things right before and after. I guess I will leave the system-set-network date off and do this. I guess I am set now.

Thanks to all.

jpollard · #10 23rd March 2012, 03:34 PM

The only thing going wrong is the local time.

The actual time has always been correct. This points to the loss of the configuration for local time - and that is up to when systemd sets/updates/whatever that value.

Everything I've seen so far has indicated that being done after the httpd server is started - which means httpd gets GMT as the local time instead of eastern daylight saving time.