tagchen.
ich wende mich mal wieder mit einem problemchen an euch.
ich hatte damals die uhrzeitsync via xntpd eingerichtet und das lief auch alles wunderbar.
konstellation:
sles8 holt sich bei einem w2k3 die zeit ab welcher wieder um einen w2k als master hat an welchem eine dcf77 angeschlossen ist.
alternative: sles8 holt sich die zeit am gateway an welches die zeit auch von einer dcf77 bekommt, bzw aus der infratruktur herraus (diese infrastruktur ist mir nicht einsehbar "nahtstelle von zuständigkeiten" ^^)
naja, soweit sogut, lief wunderbar.
aber seit dem 26.12.05 taucht dieses auf:
ich habe natürlich schon versucht was herauszufinden, nur werde ich nicht schlau daraus. zum einen interpretiere ich die aussagen diverser google-recherchen damit das zu viel traffic herrscht und das "zeitfenster" des telegramms zu gross wird.
zum anderen das die differenz zwischen hardwareuhr und zeitserver zu gross ist.
kann mir vielleicht jmd was dazu sagen?
vielleicht noch zur info, das ganze ist auf 2 oracle-db servern der fall. bei beiden seit dem 26.12.05.
am 26.12.05 wurden beide server ausgebaut und routinemässig gereinigt. ich kann mir aber kaum vorstellen was das damit zu tun hat, aber der vollständigkeithalber möchte ich das erwähnen.
gruss disco
ich wende mich mal wieder mit einem problemchen an euch.
ich hatte damals die uhrzeitsync via xntpd eingerichtet und das lief auch alles wunderbar.
konstellation:
sles8 holt sich bei einem w2k3 die zeit ab welcher wieder um einen w2k als master hat an welchem eine dcf77 angeschlossen ist.
alternative: sles8 holt sich die zeit am gateway an welches die zeit auch von einer dcf77 bekommt, bzw aus der infratruktur herraus (diese infrastruktur ist mir nicht einsehbar "nahtstelle von zuständigkeiten" ^^)
naja, soweit sogut, lief wunderbar.
aber seit dem 26.12.05 taucht dieses auf:
Code:
10 Oct 17:38:14 ntpd[1073]: running as uid(74)/gid(65534) euid(74)/egid(65534).
10 Oct 17:38:14 ntpd[1073]: frequency initialized 27.579 from /var/lib/ntp/ntp.drift
10 Oct 17:41:35 ntpd[1073]: kernel time discipline status change 41
26 Dec 06:41:10 ntpd[1073]: ntpd exiting on signal 15
26 Dec 07:09:17 ntpd[1046]: running as uid(74)/gid(65534) euid(74)/egid(65534).
26 Dec 07:09:17 ntpd[1046]: frequency initialized 28.015 from /var/lib/ntp/ntp.drift
26 Dec 07:12:46 ntpd[1046]: kernel time discipline status change 41
27 Dec 09:57:12 ntpd[1046]: time reset -0.508250 s
27 Dec 09:57:14 ntpd[1046]: synchronisation lost
27 Dec 10:17:41 ntpd[1046]: time reset 0.622040 s
27 Dec 10:17:41 ntpd[1046]: synchronisation lost
1 Jan 02:03:34 ntpd[1046]: time reset 0.194255 s
1 Jan 02:03:34 ntpd[1046]: synchronisation lost
4 Jan 09:58:56 ntpd[1046]: ntpd exiting on signal 15
4 Jan 09:59:00 ntpd[29023]: running as uid(74)/gid(65534) euid(74)/egid(65534).
4 Jan 09:59:00 ntpd[29023]: frequency initialized 28.022 from /var/lib/ntp/ntp.drift
4 Jan 10:02:17 ntpd[29023]: kernel time discipline status change 41
4 Jan 10:18:24 ntpd[29023]: time reset -0.584739 s
4 Jan 10:18:24 ntpd[29023]: synchronisation lost
10 Jan 08:49:07 ntpd[29023]: ntpd exiting on signal 15
10 Jan 08:49:10 ntpd[27253]: running as uid(74)/gid(65534) euid(74)/egid(65534).
10 Jan 08:49:10 ntpd[27253]: frequency initialized 27.951 from /var/lib/ntp/ntp.drift
10 Jan 08:49:29 ntpd[27253]: ntpd exiting on signal 15
10 Jan 08:49:31 ntpd[27342]: running as uid(74)/gid(65534) euid(74)/egid(65534).
10 Jan 08:49:31 ntpd[27342]: frequency initialized 27.951 from /var/lib/ntp/ntp.drift
10 Jan 08:52:47 ntpd[27342]: kernel time discipline status change 41
11 Jan 06:41:35 ntpd[27342]: ntpd exiting on signal 15
11 Jan 06:41:28 ntpd[22486]: running as uid(74)/gid(65534) euid(74)/egid(65534).
11 Jan 06:41:28 ntpd[22486]: frequency initialized -470.653 from /var/lib/ntp/ntp.drift
11 Jan 06:44:53 ntpd[22486]: kernel time discipline status change 41
11 Jan 07:01:57 ntpd[22486]: time reset 0.540502 s
11 Jan 07:01:57 ntpd[22486]: synchronisation lost
11 Jan 07:41:21 ntpd[22486]: ntpd exiting on signal 15
11 Jan 07:41:24 ntpd[31292]: running as uid(74)/gid(65534) euid(74)/egid(65534).
11 Jan 07:41:24 ntpd[31292]: frequency initialized -470.653 from /var/lib/ntp/ntp.drift
11 Jan 07:44:45 ntpd[31292]: kernel time discipline status change 41
11 Jan 23:31:38 ntpd[31292]: time reset -0.139053 s
11 Jan 23:31:38 ntpd[31292]: synchronisation lost
11 Jan 23:52:07 ntpd[31292]: time reset 0.715956 s
11 Jan 23:52:07 ntpd[31292]: synchronisation lost
12 Jan 06:05:55 ntpd[31292]: time reset -0.139808 s
12 Jan 06:05:55 ntpd[31292]: synchronisation lost
12 Jan 09:41:49 ntpd[31292]: ntpd exiting on signal 15
12 Jan 10:11:14 ntpd[26022]: running as uid(74)/gid(65534) euid(74)/egid(65534).
12 Jan 10:11:14 ntpd[26022]: frequency initialized 26.792 from /var/lib/ntp/ntp.drift
12 Jan 10:13:05 ntpd[26022]: ntpd exiting on signal 15
12 Jan 11:10:25 ntpd[7833]: running as uid(74)/gid(65534) euid(74)/egid(65534).
12 Jan 11:10:25 ntpd[7833]: frequency initialized 26.792 from /var/lib/ntp/ntp.drift
12 Jan 11:13:42 ntpd[7833]: kernel time discipline status change 41
12 Jan 19:12:58 ntpd[7833]: time reset -0.255861 s
12 Jan 19:12:58 ntpd[7833]: synchronisation lost
13 Jan 10:16:42 ntpd[7833]: time reset -0.318232 s
13 Jan 10:16:42 ntpd[7833]: synchronisation lost
14 Jan 14:15:02 ntpd[7833]: time reset -0.240813 s
14 Jan 14:15:07 ntpd[7833]: synchronisation lostzum anderen das die differenz zwischen hardwareuhr und zeitserver zu gross ist.
kann mir vielleicht jmd was dazu sagen?
vielleicht noch zur info, das ganze ist auf 2 oracle-db servern der fall. bei beiden seit dem 26.12.05.
am 26.12.05 wurden beide server ausgebaut und routinemässig gereinigt. ich kann mir aber kaum vorstellen was das damit zu tun hat, aber der vollständigkeithalber möchte ich das erwähnen.
gruss disco