Re: NTP bockt bei Backupsskript
am 2006-04-28 13:58 schrieb Richard Mittendorfer:
> Also sprach Peter Velan <pv0001@dynapic.net> (Fri, 28 Apr 2006 12:54:22
> +0200):
>> am 2006-04-28 11:45 schrieb Richard Mittendorfer:
>> > Also sprach Peter Velan <pv0001@dynapic.net> (Fri, 28 Apr 2006
> [...]
>> >> Immer noch gewaltige 270 Sekunden daneben! Da stinkt etwas
>> >gewaltig! > Über die selbe eth läuft - auch während das Backupskript
>> >rennt ohne zu > mucken - SMTP/POP3.
>> >
>> > Und vmstat 1?
>>
>> Macht vermutlich nur Sinn, wenn es während des Skriptlaufs gezogen
>> wird, oder? Im Moment möchte ich das Skript nicht starten, weil die
>
> Jupp. 2 x 1e Minute sollten reichen. Schick's wieder PM um nicht
> unnoetig Mailboxen zu fuellen und haeng mir noch dein /var/log/dmesg
> dazu.
Ok, nachdem die Kollegen ihre Kellen hingeschmissen und sich ins
wohlverdiente Wochende verabschieden geht es los. Ich schneide parallel
dazu mit Ethereal den ntp- und dns-Verkehr mit, vielleicht sieht man da
was Verdächtiges.
>> > Schick auch mal ein lspci -v der Box mit.
>> --- lspci -v:
> [...]
>
> Das Modem ist als Backup-Einwahlverbindung gedacht?
Hoppla, das kann man aus "lspci" herauslesen? Donnerwetter.
> Ansich nicht's
> auffaelliges dabei, ausser die rtl8139, die einen schlechten Ruf
> geniesst. Allerdings hab ich solcheine (rev. 10) ohne Nebenwirkungen in
> div. Rechnern.
Auch das kann man aus "lspci" rauskramen? Ujala.
>> > Loesche auch mal deine /var/lib/ntp/ntp.drift (vorher
>> > /e/i/ntp-server stop).
>>
>> Wenn ich das Backupskript anwerfe, lösche ich vorher die ntp.drift und
>> starte den ntp-server neu.
>
> Mach das gleich (es kann nix schiefgehen). Der ntpd braucht dann einige
> Zeit um sich zu kalibrieren.
Schon geschehen: ntp-server stop, ntp.drift weg, ntp-server start. Habe
in der ntp.conf "server de.pool.ntp.org iburst" stehen: der ntpd befragt
also nach dem Start den erwählten Zeitmaster 8-mal im 2-sek Takt ab. Bis
jetzt siehts sauber aus - das Backupskript läuft ja auch noch nicht ;-)
>> Ich habe die Kiste als Testing bekommen (als noch Woody = stable war).
>> Insbesondere wichtig war mir damals EXIM und den wollte ich schon in
>> einer moderner Fassung (EXIM4) haben. Mein Lieferant hat mir also
>> schon das Richtige verkauft.
>
> Klaro, fuer ein Produktionssytem ohne Spielerei waer' ich dann aber auf
> Sarge geblieben.
Nunja, MySQL5, PHP5, etc. sind schon Dingelchen die ich gerne hätte und
irgendwann habe ich es wohl etwas überzogen und komplett auf "testing"
geschwenkt. Ist halt jetzt so, und vielleicht ist dann der Übergang zur
etch-Release weniger schmerzhaft.
>> Habe inzwischen eine "testing" Kiste, weil ich regelmässig
>>
>> apt-get upgrade
>> mit source.list = debian.org/debian/ etch main contrib non-free
>>
>> fahre.
>
> Also bis auf den Kernel (woher ist 2.4.27custom?)
# uname -r
2.4.27linsoft-nf2
so nennt sich der Kübel.
> bist du auf aktuellem
> Etch. Testing & apt-get upgrade waer' mir auf einem Produktionssystem zu
> gefaehrlich. Normalerweise bringe ich dort einzelne Apps und hin und
> wieder weitere einzelne Bereiche des Systems auf Vordermann. Damit
> lassen sich Fehlerquellen leichter isolieren.
So habe ich auch erstmal gearbeitet, aber durch die Stabilität (von
Windows kommend ist man einfach beindruckt) bei kleineren Updates, die
über Sarge hinausgingen, habe ich mir irgendwann gesagt: komm trau dich.
Wenn man sich irgendwo Hilfe zu einem Package holen will, heisst es doch
fast immer "nimm die letzte Release" (oder gar "last CVS Snapshot") und
mit "testing" (Debian/testing ist einfach schon beeindruckend gut) war
ich halt nicht der vorgestrige Looser. Wie schon gesagt bin halt mit
einem Produktionssystem auf aktuellem Etch, ist halt jetzt so. Werde
aber künftig etwas genauer hingucken was ich wirklich brauche und nicht
so reflexartig alles nehmen ;-)
>> Seltsam halt, dass die Problem nach ca. einem Jahr ruhigem Betrieb
>> jetzt erst auftreten :-(
>
> Das macht die Fehlersuche ja so schwierig. Generell ist das Betragen
> recht seltsam, da lediglich der ntpd (Netzwerk)Probleme zu haben scheint
> und deine Uhr durch die Belastung des Backupscripts 5min/hr verliert,
> was ich wiederum gern auf das PCI/IDE-Subsystem schieben wuerde.
Hmm, ob der smbmount das Problem ist? Ich mounte ganz am Anfang des
Backupskripts, sichere aber zuerst die lokalen Daten - und da steigt der
Wecker schon aus. Aber immerhin ist der Mount schon aktiv!?
> Das es erst jetzt ersichtlich wird, kann daran liegen, dass das
> Backupvolumen ueber einen kritischen Wert angewachsen ist. Dagegen
> spricht aber, dass das ntp-timeout schon nach wenigen Minuten auftritt.
eben.
> Im Uebrigen ist's wohl nicht die Schuld des ntpd. Schon eher deine
> Systemuhr (nicht Hardwareclock) die hier verrueckt spielt.
Ok, aber warum dann:
28 Apr 04:15:23 ntpd[8042]: no servers reachable
Das hat doch sicher nichts mit dem interne Wecker zu tun, oder?
> Daher wuerde
> ich mal auf einen modernen Kernel umsteigen. Davon erhoffe ich mir
> Besserung.
Tja, wie gesagt, das traue ich mir selber nicht zu :-(
Ciao,
Peter
Reply to: