Re: NTP bockt bei Backupsskript
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.
> Kollegen noch arbeiten. Wenn die Kiste freier ist, starte ich das
> Backupskript und lass "vmstat 1" mitlaufen. Dennoch vorab schon mal:
>
[...]
> > Waer' interessant, wie's den interrupts dabei geht. Hast
> > du acpi aktiviert?
>
> Kein acpi:
> --- proc/interrupts:
OK.
> > Schick auch mal ein lspci -v der Box mit.
> --- lspci -v:
[...]
Das Modem ist als Backup-Einwahlverbindung gedacht? Ansich nicht's
auffaelliges dabei, ausser die rtl8139, die einen schlechten Ruf
geniesst. Allerdings hab ich solcheine (rev. 10) ohne Nebenwirkungen in
div. Rechnern.
> > 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.
> > Ich will dir zu keinen weiteren Wuergarounds raten. Bring lieber das
> > System bzw. hier involvierte Applications und vor allem den Kernel
> > auf einen aktuellen oder stabilen Stand. Du hast geschrieben, es
> > waer' eine Mischung aus stable und testing.
>
> 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.
> 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?) 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.
> 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.
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.
Im Uebrigen ist's wohl nicht die Schuld des ntpd. Schon eher deine
Systemuhr (nicht Hardwareclock) die hier verrueckt spielt. Daher wuerde
ich mal auf einen modernen Kernel umsteigen. Davon erhoffe ich mir
Besserung.
> Danke und Gruß,
> Peter
sl ritch
Reply to: