apt-get hängt sich auf

[Nelson]

Hallo,

ich habe auf einem Xen-Server (2.6.26-1-xen-amd64) mehrere VMs (Debian) installiert und bei einigen VMs stelle ich bei der Paketeinstallation mit apt-get fest, daß der Prozess hängen bleibt:

Code: Alles auswählen

0 aktualisiert, 0 neu installiert, 0 zu entfernen und 6 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0B Plattenplatz zusätzlich benutzt.
Richte egroupware-egw-pear ein (1.4.004-2-1) ...

und

Code: Alles auswählen

# ps aux | grep apt-get
root     11801  0.0  5.7  31744 15008 pts/0    S+   10:02   0:00 apt-get install php-pear egroupware-egw-pear

Gibt es für dieses Problem eine Lösung, so daß sich die Programme installieren lassen?

Grüsse

Nelson

[KBDCALLS]

Versuche mal

Code: Alles auswählen

apt-get install -f

Müßte er dir aber als Lösung anbieten.

[jhr-online]

Passiert das nur bei dem einen Paket oder grundsätzlich ab und zu mal?

jhr

[Nelson]

Ich würde mal sagen, das passiert mir auf den Gast-VMs unter XEN, egal welches Paket. Der XEN-Server (Dom-0) hat da keine Probleme.
Und "apt-get install -f" macht jetzt insofern etwas, daß er das z.B.

Code: Alles auswählen

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 12 nicht aktualisiert.
9 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0B Plattenplatz zusätzlich benutzt.
Richte php5-common ein (5.2.6.dfsg.1-1+lenny2) ...
Richte libapache2-mod-php5 ein (5.2.6.dfsg.1-1+lenny2) ...
Reloading web server config: apache2.
Richte php5-cgi ein (5.2.6.dfsg.1-1+lenny2) ...

Creating config file /etc/php5/cgi/php.ini with new version
Richte php5-cli ein (5.2.6.dfsg.1-1+lenny2) ...
Richte php5-gd ein (5.2.6.dfsg.1-1+lenny2) ...
Richte php5-imap ein (5.2.6.dfsg.1-1+lenny2) ...
Richte php5-ldap ein (5.2.6.dfsg.1-1+lenny2) ...
Richte php5-mysql ein (5.2.6.dfsg.1-1+lenny2) ...
Richte php5-xmlrpc ein (5.2.6.dfsg.1-1+lenny2) ...

und ebenfalls hängen bleibt.
Ich möchte meinen, die Sachen werden teilweise schjon installiert, nur scheint apt-get beim letzten Paket sich aufzuhängen. In syslog finde ich auch keine Fehlermeldungen. Ich sehe nur über ps, daß der Prozess sozusagen schläft.

Grüsse

Nelson

[KBDCALLS]

Da wird doch bestimmt noch noch ausgegeben. Das ist doch nicht alles.

[Nelson]

Wenn ich weiß wo, dann sage ich es sofort. Eben nein. Der Prozeß bleibt an den besagten Punkten hängen, dann habe ich in der Standardausgabe auch nichts weiteres stehen. Ich wäre sicherlich weiter, wenn da noch irgendwie Meldungen mitgeschickt würden. Dann suche ich nämlich erstmal explizit nach diesen Meldungen im Web.
Ich habe schon gedacht, daß das vielleicht mit der neuen XEN-Version auf Lenny zu tun haben könnte.

[KBDCALLS]

Was ergibt denn

Code: Alles auswählen

dpkg --audit 

[Nelson]

Letztenendes gar nichts. Die Ausgabe bleibt auch leer. Ich habe inzwischen auch schon festgestellt, daß die besagten Pakete fehlerfrei installiert sind. Offensichtlich beendet apt-get sich nicht korrekt.
Ich habe vor ein paar Tagen das gleiche Problem mit dpkg -i <Paketname> gehabt. Auch hier hat sich der Prozeß aufgehängt bzw. nicht beendet.

[jhr-online]

Ich bin nicht sicher, aber ich werd das Gefühl nicht los, dass du ein anderes, größeres Problem hast.

jhr

[Nelson]

Solche Gefühle kenne ich. Nur in der EDV spielen Emotionen keine Rolle, zumindest heutzutage noch nicht - das Limbische System kann noch kein Rechner abbilden. Ergo müsste eine logische, technische Lösung geben. Und wenn das nur ein Problem der Dom-U ist.

Grüsse
Neslon

[Jojo66]

Hallo zusammen,

genau das gleiche Problem hatte ich bis gerade eben auch. Etch in einer VM und atp-get hängt sich auf. Ich hab probeweise eine Neuinstalltion mit einem frischen Etch-Iso in der Businesscard-Version versucht. Dabei passierte genau das gleiche.

Als ich dann mal die Neuinstallation mit Lenny probiert habe, funktionierte es.
Was mir auffiel war, dass die Installation der nachgeladenen Pakete mit Lenny viel länger dauerte als bei der Etch Version.
Die Erklärung ist, dass hier im Netz sämtlicher http-Verkehr über einen Proxy geht(ipcop). Die Pakete für Etch kamen also aus dem Proxy, während die Pakete für Lenny direkt aus den Netz kamen.
Nachdem ich den Proxycache gelöscht hatte, funktionierte auch apt-get wieder.

Vielleicht ist sowas ja auch die Ursache für Nelsons Problem.

[Nelson]

Die Erklärung ist, dass hier im Netz sämtlicher http-Verkehr über einen Proxy geht(ipcop). Die Pakete für Etch kamen also aus dem Proxy, während die Pakete für Lenny direkt aus den Netz kamen.
Nachdem ich den Proxycache gelöscht hatte, funktionierte auch apt-get wieder.

Vielleicht ist sowas ja auch die Ursache für Nelsons Problem.

Neee, das glaube ich nich. Denn da seh ich keinen Unterschied. Ich denke, das Problem insoweit gelöst zu haben, daß ich mir mal den Speicherverbrauch angesehen habe.
Ich habe für die Dom0 512MB RAM eingesetzt, das ist auch kein Problem, da sind trotz mit installierten HylaFax noch 234 MB frei. Anders habe ich bei den DomU's 256MB RAM angesetzt. Na und da gehts teilweise runter bis auf 4MB. Also war meine Lösung, die 5120MB RAM nicht auf 18 VM plus XEN-Server zu verteilen, sondern jeder VM 512MB zu zugestehen.

Mich wunderte bloß, daß die 256MB Platten-Swap nicht genutzt wurden. In den /etc/fstab's steht

Code: Alles auswählen

/dev/sda1       none            swap    sw              0       0

drinnen und

Code: Alles auswählen

swapon /dev/sda1
swapon: /dev/sda1: Das Gerät oder die Ressource ist belegt

sagt eigentlich, daß der Swap-Bereich genutzt werden sollte. Wird er aber nicht

Code: Alles auswählen

free -m
             total       used       free     shared    buffers     cached
Mem:           256        249          6          0         59        147
-/+ buffers/cache:         42        213
Swap:          255          0        255

Das wäre an dieser Stelle noch mein einziges Problem. Das Erstere sehe ich als gelöst an.

Grüsse von Nelson