Re: NTP bockt bei Backupsskript
am 2006-04-27 02:54 schrieb Richard Mittendorfer:
> Also sprach Peter Velan <pv0001@dynapic.net> (Thu, 27 Apr 2006 01:36:13
> +0200):
>> am 2006-04-27 00:38 schrieb Richard Mittendorfer:
>> > Also sprach Peter Velan <pv0001@dynapic.net> (Wed, 26 Apr 2006
>> > 23:35:35 +0200):
>> > [BACKUP AUF DVD ...]
>> >> --- zeitgleich Log des NTP-Servers:
>> >>
>> >> 23 Apr 07:00:39 ntpd[26636]: kernel time sync enabled 0001
>> >> (es war 2 Tage Ruhe, weil das Backupskript ausgeschaltet wurde)
>> >>
>> >> # Backupvorgang startet um 4:00
>> >>
>> >> > 25 Apr 04:13:01 ntpd[26636]: no servers reachable
>> >> > 25 Apr 05:46:34 ntpd[26636]: synchronized to 82.96.64.2, stratum
>> >1 > > 25 Apr 05:52:04 ntpd[26636]: time reset +330.203387 s
>> >> > 25 Apr 05:56:26 ntpd[26636]: synchronized to 82.96.64.2, stratum
>> >1 >
>> >> Die Uhr läuft also um satte 330 Sekunden zu langsam bis sie endlich
>> >> nachgeführt wird :-((
>> >
>> > Laeuft die Systemzeit ohne ntpd auch so unrund / zu langsam?
>>
>> Glaub ich zwar nicht, aber ich stopp den ntpd jetzt mal und schau mal
>> welche Zeit morgen früh angezeigt wird.
>
> Bevor du den ntpd wieder anwirfst, einfach mal "# ntpdate pool.ntp.org"
> aufrufen. Die Differenz wird angezeigt.
Ok, danke für den Tipp (bevor ichs noch mit meiner Armbandzwiebel
vergleiche).
>> > Ja, merkwuerdig. Kernel mal gewechselt?
>>
>> Nein, das einzig "kernel"-artige war ein:
>> 2006-04-10 08:19:20 upgrade nfs-kernel-server 1:1.0.7-3 1:1.0.7-9
>
> Was wurde in der Zeit upgedatet?
Naja, ich fahre den Rechner schon ziemlich nah am aktuellen "testing".
Ist gar nicht so einfach bei den vielen Updates den möglichen Übeltäter
zu lokalisieren :-(
>> Wobei ich nach einiger Überlegung zu dem Schluss kam, dass ich ja NFS
>> gar nicht nutze, also habe ich NFS komplett deinstalliert.
>>
>> Könnte *das* die Übelstelle sein?
>
> Nein, aber irgendwas muss sich getan haben. Was fuer ein Kernel ist's?
2.4.27 custombuild vom Lieferanten - Habe den Rechner im September 2004
fertig installiert gekauft und mich seitdem in die Materie versucht
reinzuarbeiten. Ein Experte bin ich nicht gerade, eher ein lernwilliger
Newbie.
> Ich _vermute_ ein Problem in diese Richtung. Genauer gesagt, dass das
> Schreiben auf DVD und/oder hohe Netzaktivitaet zumindest das Netz/System
> blockiert. Der ntpd hat IIRC ein timeout von einer Minute. Noch nicht
> gesehen, aber anders kann ich mir nicht erklaeren, dass der Server nicht
> erreicht wird.
Ja, nachdem ntpd einmal meldet keine Verbindung zu haben, tackert er
dennoch im typischen minpoll-Rhythmus von ca. 64 Sekunden den
Referenzrechner ab - aus peerstats:
> 53851 26615.902 82.96.64.2 9014 211.941109106
> 53851 26681.905 82.96.64.2 9014 211.941109106
> 53851 26747.904 82.96.64.2 9014 218.641563948
> 53851 26812.903 82.96.64.2 9014 218.641563948
> 53851 26876.902 82.96.64.2 9014 227.421936493
> 53851 26942.125 82.96.64.2 9014 227.421936493
> 53851 27005.905 82.96.64.2 9014 227.421936493
Dennoch steigt der Offset wie man oben sieht, ziemlich flott und
unafhörlich weiter :-(
> Beides (backup&ntp) geht ueber die selbe Eth?
Nein, sind zwei eth im System: die smbmounts gehen über die interne
eth1, ntpd fragt die externe eth0 ab.
> Was sagt /proc/interrupts? Ist die System- und/oder Netzlast waehrend
> des Backups sehr hoch (vmstat 1)? Ich weiss nicht, wie growisofs auf
> nice reagiert (wegen writebuffer lass's lieber nice 0), aber ein Versuch
> mit und ohne nice 19 fuers tar'en koennte was tun. Einige sleep's im
> Script loest dein Problem evtl. auch.
Gleich wird das Backupskript angeworfen - den growisofs habe ich wieder
auf nice 0 gesetzt, mal sehen was gleich passiert.
Danke für die Tipps.
Peter
Reply to: