Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: stevezemlicka on December 02, 2009, 04:50:12 PM
-
I installed a server with SME. All it is doing currently is acting as a squid proxy and monitoring traffic with SARG. I have noticed the cron jobs don't seem to be running. It turns out the date/time is all messed up. When I logged in today (12/2/09) it had a date of 11/26/09. I noticed the time issue when I first set it up but I switched it to manual and set the date/time manually and deployed it.
Now, I set it up to sync with the NTP Server nist1-chi.ustiming.org (NIST Server) and it corrected the date but the time was still around 40min off.
Additionally, if I sit there and refresh the page frequently, sometimes the seconds go down instead of up.
My question is, who developed the Time Travel Contrib and how do I disable it :lol:
Just kidding, does anybody know why the time is such a problem. Such a basic feature was the last thing i expected to run into a problem with but it is grinding the functionality of this server to a halt since it relies on cron jobs for the SARG reports.
-
Is your SME running as a virtual system? http://forums.contribs.org/index.php?topic=32139.0
-
no, it is running natively
-
I use the default smeserver.pool.ntp.org and haven't had any time issues.
-
no, it is running natively
What is the output of the following commands:
db configuration show ntpd
service ntpd status
ntpq -pn
-
johnp, I believe that was what was in after the initial install when I first noticed the problem. I don't think it's a problem with the time server or syncing with the time server, I think it's the elapsed time between syncs that is all messed up.
Cactus, here is the output:
[root@sme ~]# db configuration show ntpd
ntpd=service
MemLimit=12000000
NTPServer=nist1-chi.ustiming.org
SyncToHWClockSupported=yes
status=enabled
[root@sme ~]# service ntpd status
run: /service/ntpd: (pid 9010) 517733s, normally down; run: log: (pid 2971) 601349s
[root@sme ~]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
208.66.175.36 .ACTS. 1 u 933 256 377 31.408 2424991 2529536
*127.127.1.0 LOCAL(0) 10 l 225 64 377 0.000 0.000 0.004
I see that sync to hardware clock is enabled. Is there a way to disable that? Otherwise, I would have to make a trip onsite to check the BIOS clock. I am pretty sure the BIOS battery is OK because there aren't any issues booting (usually you should get some indication during post that the BIOS lost settings).
-
Cactus, here is the output:
[root@sme ~]# db configuration show ntpd
ntpd=service
MemLimit=12000000
NTPServer=nist1-chi.ustiming.org
SyncToHWClockSupported=yes
status=enabled
[root@sme ~]# service ntpd status
run: /service/ntpd: (pid 9010) 517733s, normally down; run: log: (pid 2971) 601349s
[root@sme ~]# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
208.66.175.36 .ACTS. 1 u 933 256 377 31.408 2424991 2529536
*127.127.1.0 LOCAL(0) 10 l 225 64 377 0.000 0.000 0.004
Here you can read up more on the interpretation of this output ( http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=953153 ), but it seems all your probes are answered (377), however the value for delay is way to high (2424991). If this is more than 128 (seconds) syncing stops.
Some advice on how to post more readable output in the future, please try and use the code block (for fixed with output such as command line output) as this will make your output a little bit more readable (like above).
I am not sure why you decided to use this setup, but at the moment you are syncing to one server only, normally at least three are configured, making things a little more robust. Was there a specific reason for reconfiguring this instead of using the default pool (smeserver.pool.ntp.org).
I have never had issues with this, nor have we had many reports there are issues.
If you are to do so you should be able to it like this:
db configuration delprop ntpd NTPServer
/etc/e-smith/events/actions/initialize-default-databasesAbove would restore the database value to the default value again.
After that you will have to regenerate configuation files and restart affected services:
signal-event timeserver-update
I would at least configure more hosts or even better IMHO revert to the default behavior if there are no specific reasons for using this source.
Any way you need to try and sync your clock as it will not sync without manual intervention (whether you reverted settings or not).
To try and get things back in sync you can try the following commands:
ntpdate -b serverwhere you should replace "server" with the hostname or IP address of the server to sync against. You might need to repeat this step as the clock might be set there in steps and not on one step. You can check using the ntpq command I showed you earlier.
I see that sync to hardware clock is enabled. Is there a way to disable that? Otherwise, I would have to make a trip onsite to check the BIOS clock. I am pretty sure the BIOS battery is OK because there aren't any issues booting (usually you should get some indication during post that the BIOS lost settings).
AFAIK sync to BIOS works the other way around, the BIOS clock is synced with the time retrieved.
-
I would also add to change manually the date/time setting via server-manager panel or via CLI before setting ntp server again.
in my experience when the difference between local value and the ntp server one is big, there's no syncronization
my 2c
-
I would also add to change manually the date/time setting via server-manager panel or via CLI before setting ntp server again.
You can also do that, might be easier than my solution I guess.
in my experience when the difference between local value and the ntp server one is big, there's no syncronization
Yep, that is the 128s (2 mins) I mentioned.
-
You can also do that, might be easier than my solution I guess.
Yep, that is the 128s (2 mins) I mentioned.
well, I think it's time I stop working till 2 o'clock in the morning.. ;-)
-
Great advice. I noticed the issue with the clock before I changed anything (within about 30 min after completing the SME install). So I set the time manually. It wasn't until after I deployed it and saw it still wasn't working that I specified that Chicago (in my area) time server. I have not changed anything in the configuration except switching it to manual and then switching it back to sync with a time server. Everything I have done regarding the time server has been via the web interface.
I will try cactus' reset procedure but if it just puts it back to the original configuration, I think the problem is likely to continue. I will post back after I have tried that.
-
OK, I tried to reset everything and here is what I got.
[root@sme ~]# db configuration delprop ntpd NTPServer
[root@sme ~]# /etc/e-smith/events/actions/initialize-default-databases
Migrating existing database backups
Migrating existing database yum_installed
Migrating existing database spamassassin
Migrating existing database networks
Migrating existing database yum_repositories
Migrating existing database yum_available
Migrating existing database accounts
Migrating existing database configuration
Migrating existing database hosts
Migrating existing database mailpatterns
Migrating existing database domains
Migrating existing database yum_updates
[root@sme ~]# signal-event timeserver-update
[root@sme ~]# ntpdate -b smeserver.pool.ntp.org
Error : Name or service not known
8 Dec 13:23:09 ntpdate[9855]: can't find host smeserver.pool.ntp.org
8 Dec 13:23:09 ntpdate[9855]: no servers can be used, exiting
[root@sme ~]# ntpdate -b time.nist.org
8 Dec 13:23:11 ntpdate[9856]: the NTP socket is in use, exiting
[root@sme ~]#
While the date is Dec 8th, the time was 1:45pm when I ran this.
And the time continues to be inaccurate. It is now 2:45pm and the "Current setting" is 1:26:36 PM CST
-
And the time continues to be inaccurate.
Don't report problems here - Please report bugs and potential bugs in the bug tracker
-
Don't report problems here - Please report bugs and potential bugs in the bug tracker
OK, I apologize. Up to this point, I followed my logical troubleshooting process which is to post my question in the forum and respond appropriately. I will post this in the bug tracker. Thanks for your help.
Is there a guide for what I should include in the bug report? If not, please give me suggestions. I want to try to get this taken care of as quickly and efficiently as possible.
-
I have seen some references regarding CentOS and timekeeping to disabling ACPI and/or APIC (http://support.ntp.org/bin/view/Support/KnownOsIssues). Does anybody think this is something to try?