Smart/Fehlermeldungen
Autoren: emoenke und oc2pus
Zitat:
Failed acquiring information for 'SUSE Linux packages apt-rpm repository on ftp.gwdg.de':
http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.0-i386/base/pkglist.security.bz2: Server reports unexpected size
Das liegt sehr wahrscheinlich an einem unvollständigem Mirror-Lauf des apt-Servers.
Man kann als Protokoll ftp:// statt http:// probieren und/oder einen anderen Mirror einsetzen.
Diese Anpassung erfolgt entweder via GUI - > EDIT -> Channels oder in der entsprechenden Channel-Datei in /etc/smart/channels/ ...
Wenn man die Channel-Datei anpasst, wird man beim nächsten smart update gefragt ob man die "Differenzen" neu übernehmen will.
Das liegt immer an einer "in progress" befindlichen Aktualisierung der "echten" Metadaten des Repositories (nicht der Symlinks, die zu den eigentlichen .rpm-Files fuehren).
Es sind jetzt 16 Repositories, und alle 4 Stunden wird in ftp4 die Aktualisierung angestossen. Alle 16 gleichzeitig - das ist die einzige Chance, etwas von der I/O-Leistung des Filesystems für meine eigenen Prozesse abzubekommen. ;-)) Das neue Repository ersetzt das alte auf einen Schlag (durch einen mv-Befehl ganz zum Schluss). Wenn eine Repository-Erzeugung nach 4 Stunden noch nicht fertig ist, fällt die nächste einfach aus. Dadurch ist der Zustand der Repositories selbst im ftp4 immer "integer", aber zwischen Anfang der Erzeugung und dem Ende der nächsten Erzeugung kann sich in den Directories, in denen die RPM-Files wirklich liegen, etwas geändert haben. Dann stimmt das Repository, aber ein .rpm-File ist nicht mehr da. Ein solcher Fehler sollte irgendwie mit "file not found" gemeldet werden. Spätestens nach 4 Stunden (im Mittel nach zwei Stunden) ist so ein Fehler wieder weg, weil das neue File im nächsten Repository drin ist. Diese Schwachstelle ist prinzipieller Natur, weil das Repository erst im Server und nicht schon beim Maintainer erzeugt wird.
Zur nächsten vollen Stunde startet ftp den Abgleich der Repositories (auch 16-fach parallel, um gegen die User anstinken zu können). Dieser Abgleich muss leider inkrementell gehen, d.h. direkt in das aktuelle Repository. Ich kann nicht vorher eine Kopie des aktuellen Repositories ziehen, in Ruhe die Kopie abgleichen und dann zum Schluss wie im ftp4 mit einem mv-Befehl "switchen", weil das Kopieren der durchschnittlich mehr als 15 000 Links pro Repository im belasteten Filesystem viel zu lange dauern würde.
Wenn während des Abgleichs einer der Links auf ein .rpm-File nicht mehr stimmt (oder noch nicht - das kann im ftp auch vorkommen, weil er die Metadaten ja nicht selbst erzeugt), gibt es eine Fehlermeldung der Art "file not found", wie sie auch beim ftp4 vorkommen kann.
Wenn sich aber bei den echten Metadaten-Files in der Directory base alte und neue Files mischen (hashfile, mrlist.*, pkglist.*, release, release.*, srclist.*), gibt es die Fehlermeldung, auf die ich hier antworte oder eine ähnlich kuriose, z.B. dass eine MD5-Summe nicht stimmt, die jedenfalls auf interne Unstimmigkeiten hinweist).
Diese base-Directory eines jeden Repositories ist im Schnitt nur 100 MB gross, aber vorgestern hat ein einzelner Prozess nur mit 1 MByte pro Minute in das Filesystem schreiben können (statt > 100 MByte pro Sekunde, wenn der Prozess "alleine" wäre). D.h. wir hatten in jedem Abgleich fast zwei Stunden lang immer wieder dieses zentrale Unstimmigkeits-Risiko. Zum Glück ist jeder zweite Abgleich ausgefallen, weil das 4-Stunden-Intervall nicht gereicht hat. ;-))
Heute sind im ftp auch wieder zwei von 6 Abgleichen ausgefallen, weil der Vorgänger noch nicht fertig war, aber ich spür's schon in den Knochen: es bessert sich bald wieder.
Zum Wechsel zwischen http:// und ftp://:
Das bringt nur etwas, falls man am Session-Limit abgewiesen wird. Das war aber seit letzter Woche nicht mehr der Fall.
Gruss -e
