Could not synchronize time with <node name>

[bonovox73]

Goodmornig,

I have a structure with 3 nodes:

GBACKS1  (this is the storage pool autority)

GBACKS2

GBACKS3

From 4 days I have this critical alert from GBACKS3:

[]Could not synchronize time with GBACKS1P

I checked the time from O.S. level and it is the same.

I would say:

- how puredisk sincronize time between nodes ( is there a policy or a job that runs?)

- how can I check time from storage pool autority of nodes

- how can I solve problem.

Please anyone can help me?

Thanks

[S_Williamson]

Hi

First Check your ntp is running

# /etc/init.d/ntp status
Checking for network time protocol daemon (NTPD):                     running

if not start it

# /etc/init.d/ntp start

the ntp you sync with should have been set in yast2 (or when you did your config)

to see if your syncing is working run the command

 # ntpq

then type in peers

ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*yourserver.domain 192.168.1.46      4 u   58   64  377    0.112    0.214   0.059

if you see a * next to your time server its in sync, if no * then not in sync, if you only just started the ntp (or restarted it) you may need to give it 1 to 2 mins

Personally I dont sync between nodes. I get them to sync to a server running a time service on our domain.

regards

Simon

[bonovox73]

Thanks Simon,

These are ouputs of checks

From Storage pool authority GBACKS1:

GBACKS1P:/etc/init.d # ./ntp status

Checking for network time protocol daemon (NTPD):                     running

GBACKS1P:~ # ntpq

ntpq> peers

     remote           refid      st t when poll reach   delay   offset  jitter

=======================================================

*192.168.212.20  193.204.114.232  2 u   16   64  377    0.625    1.030  13.560

From GBACKS3 (node that give me the warning)

GBACKS3:~ # /etc/init.d/ntp status

Checking for network time protocol daemon (NTPD):                     running

ntpq> peers

     remote           refid      st t when poll reach   delay   offset  jitter

=====================================================

*GBACKS1P        .STEP.           1 u  599 1024  377    0.360  -190.06 196.881

As you can see the SPA syncs from 192.168.212.20 (that is my domain controller) and the deamon is running.

GBACKS3 syncs from GBACKS1 but it seems that is Ok

Don't ask my why the sync is from the SPA node because the configuration was done by my chief, I only follow things where there are problems...

So now, from SPA interface I can see that this critical alert has the same hour every day:

16-ott-2010 14.02.11

17-ott-2010 14.02.04

18-ott-2010 14.02.06

19-ott-2010 14.01.47

The application is:

SendEvent

The source of the event is:

SendEvent_SendEvent

The description is:

[]Could not synchronize time with GBACKS1P

Any other info I can find about the message. i don't know if clock sync is done by O.S. level or by SPA level, in this case there should be a job or a policy configured...

Do you have any idea?

Thanks

Christian

[Tom_Burrell]

You really ought to be syncing NTP to a box elsewhere- and having the other boxes do the same.  That will keep your time stamps aligned with the client boxes better.  It looks like someone wanted to keep the boxes syncronized with each other- an excellent goal, but probably not the best way to accomplish it- you should have them all sync to the 192.168.212.20 box instead.  This is what I do and it works fine.

By the way- did this ever work?

[bonovox73]

Thanks Tom,

I don't know why and if it is why, but after checks that I did yesterday, the warning is disappeared.

Now I'm looking for some days if will come back.

I will consider to sync all nodes from 192.168.212.20.

Thanks at all

Christian

[S_Williamson]

One reason it may be failing is if the name resolution of GBACKS1 can not be done at that time. Either create a host entry for it but better change it to the IP of your domain controller (or NTP box)

If you need to change the setting, use vi to edit the file /etc/ntp.conf

Then restart the ntp daemon

look for the lines

logfile /var/log/ntp
server ntp.yourserver.domain

In your case its probably

server GBACKS1

and change to

server 192.168.212.20

Simon

[bonovox73]

Today the warning was appeared yet,

I checked the /etc/ntp.conf for the GBACKS3 and there is the name of the storage pool authority node GBACKS1 and not the ip address.

So what you say Simon, could be right, but there is the node GBACKS2 that has the same entry in /etc/ntp.conf as GBACKS3 and it never had problems.

I have checked the ntp deamon status and the ntpd peers yet and the output is true:

GBACKS3:~ # /etc/init.d/ntp status
Checking for network time protocol daemon (NTPD):                     running
GBACKS3:~ # ntpq
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
=======================================================
*GBACKS1P        192.168.212.20   3 u   33  128  377    0.322    1.124   2.129

I don't know....

[S_Williamson]

Well as long as the * is next to GBACK1SP your not having an issue. Maybe at certain times its unable to resolve the name so as I suggested add it to your local host file.

Also another issue maybe is there may be a time out value. If you dont get a vaild response within that time period it gives you an error. Either way, as long at the time is correct I'd ignore it. :)

Simon

[bonovox73]

Yesterday I rebooted all machines but today I have the same issue.

I verified with "ntpq - peers" command and I can see the "*"

Simon, you tlk about a time out, is there the possibility to increase this value?

Thanks

[Abesama]

There's no external NTP server configured, and I also get this error from only few of the nodes, not all the nodes.

To me it seems something about network/delay ...

The nodes giving this error are either SPA or CR

And the timing is when one of the CR queue processing jobs is running

bonovox73, have you made all 3 sync from 192 ...?

You have one person here who's very much curious if that will stop the alerts in your env.

Abe