hallo,
ich habe ein gravierendes problem entdeckt.
siduction stürzt ab, wenn es in einer virtuellen maschine installiert ist. und zwar dann, wenn ich mehrmals hintereinander "apt-get update" ausführe. das erste mal geht problemlos, das zweite mal vielleicht auch noch. aber beim soundsovielten mal hintereinander wird die gesamte virtuelle maschine abgebrochen.
dies passiert, wenn ich siduction direkt installiert habe, also noch praktisch nichts konfiguriert.
ich habe dies auf zwei rechnern probiert.
auf einer siduction maschine und auf einem debian-testing.
gruß, christian
Vielleicht solltest Du uns ein paar Informationen zukommen lassen: Was für eine virtuelle Maschine? VM-Ware oder virtuell-box? Wieviel Speicher hat die VM von wieviel Gesamtspeicher? Wie sieht die Patitionierung und die Bereitstellung der virtuellen Festplatte aus? NAT oder direktes Netzwerk? Irgendwelche Auffälligkeiten in den logs nach dem Abbruch? Passiert dies auch bei anderen Distributionen oder expliziet nur bei siduction?
Quote from: "cas"hallo,
ich habe ein gravierendes problem entdeckt.
siduction stürzt ab, wenn es in einer virtuellen maschine installiert ist. und zwar dann, wenn ich mehrmals hintereinander "apt-get update" ausführe. das erste mal geht problemlos, das zweite mal vielleicht auch noch. aber beim soundsovielten mal hintereinander wird die gesamte virtuelle maschine abgebrochen.
dies passiert, wenn ich siduction direkt installiert habe, also noch praktisch nichts konfiguriert.
Dein Speicher läuft vermutlich voll- den hast du dann aber für deine virtuelle Maschine meines Erachtens einfach zu klein ausgelegt. Mache zwischendurch ein
apt-get clean oder noch besser-- vergrößere den Speicherbereich.
Ein n-ter Run von apt-get update sollte keine neuen Daten erzeugen. Und ein erster Run erzeugt bei täglicher Ausführung rund 500 kb. Am Speicher wirds also nicht liegen, es sei denn, er ist generell zu klein.
greetz
devil
Quote from: "devil"Ein n-ter Run von apt-get update sollte keine neuen Daten erzeugen. Und ein erster Run erzeugt bei täglicher Ausführung rund 500 kb. Am Speicher wirds also nicht liegen, es sei denn, er ist generell zu klein.
Naja, ich vermutete, dass es nicht nur beim update blieb, sondern dass da u.U. ein dist-upgrade dahinter laufengelassen wurde...
Quote from: "captagon"Naja, ich vermutete, dass es nicht nur beim update blieb, sondern dass da u.U. ein dist-upgrade dahinter laufengelassen wurde...
Nein, ich habe das nochmals mit einer frischen VM reproduzierbar ausprobiert.
HOST: siduction reloaded, DU gestern, frische HW:
cas@dino:~$ inxi
CPU~Quad core Intel Core i5-3570K CPU (-MCP-) clocked at 1600.000 Mhz Kernel~3.6-0.towo-siduction-amd64 x86_64 Up~6:19 Mem~1421.5/7886.7MB HDD~2208.5GB(35.8% used) Procs~175 Client~Shell inxi~1.8.15
GAST: siduction reloaded
das Einrichten geht standardmäßig, fast ohne Änderungen von den Vorgaben folgendermaßen vor sich:
1) VM in VB erstellen
auf 700 MB RAM erhöhen
in VB unter "Ändern":
Diskette entfernt
Siduction.iso an IDE-Controller eingebunden
2) VM starten (von angeschlossener ISO aus)
3) in VM
mit gparted
a) Partitionstabelle erstellen
b) 2 Partitionen erstellen: 6,5 GB ext4 sda1; 1,5GB swap sda2
4) auf so eingerichteter HD sidu-installer laufen lassen
5) reboot (ohne ISO)
6) Wenn ich in dieser jungfäulichen Maschine mehrmals apt-get update laufen lasse (wo ich sonst noch gar nichts getan habe), stürzt sie reproduzierbar ab.
In der linke Spalte von VB, steht dann "abgebrochen" (mit Einbahnstrassensymbol) statt "ausgeschaltet" bzw. "wird ausgeführt".
Speicher des Gastes sieht nach Neustart so aus:
cas@siductionbox:~$ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
rootfs 6,5G 3,2G 3,1G 51% /
udev 10M 0 10M 0% /dev
tmpfs 69M 388K 69M 1% /run
/dev/disk/by-uuid/371eb172-d7bc-444a-9551-77d7121ab2b7 6,5G 3,2G 3,1G 51% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 443M 0 443M 0% /run/shm
cas@siductionbox:~$ free -h
total used free shared buffers cached
Mem: 688M 466M 221M 0B 19M 218M
-/+ buffers/cache: 228M 459M
Swap: 1,5G 0B 1,5G
cas@siductionbox:~$ inxi
CPU~Single core Intel Core i5-3570K CPU (-UP-) clocked at 3396.392 Mhz Kernel~3.4-4.towo-siduction-686 i686 Up~11 min Mem~245.5/688.7MB HDD~8.6GB(-) Procs~122 Client~Shell inxi~1.8.5
cas@siductionbox:~$
Auf meiner Arbeitsstelle brauche ich eine VM. Dort war es mir aufgefallen, weil ich zweimal hintereinander "apt-get update" ausgeführt hatte. Zweimal hintereinander "apt-get update" ausführen, kann ja beim arbeiten durchaus mal vorkommen.
Warum auch immer, ist es bei oben beschriebener jungfräulichen VM nicht ganz so schlimm.
Aber spätestens nach dem sechsten mal hintereinander "apt-get update" stürzt die Maschine ab.
Zwar wird man selten so oft hintereinander "apt-get update" ausführen, dennoch ist das so für mich nicht brauchbar.
Wie gesagt, bei mir ist es reproduzierbar. Wundert mich, dass das bei niemandem anders so ist.
Bei einer frischen VM, in der squeeze installiert wurde, passiert dies nicht.
Bin ratlos.
Viele Grüße, Christian
Bei einer 64bit-siduction VM ebenfalls Abbruch.
Der Abbruch ist insofern jeweils abrupt, als bspw. die bash-history nicht mehr geschrieben wird.
Start von der Kommandozeile gibt leider keine Fehlermeldung.
cas@dino:~$ VBoxManage startvm sidu64
Waiting for VM "sidu64" to power on...
VM "sidu64" has been successfully started.
cas@dino:~$
In den logs innerhalb von /var/log konnte ich nichts entdecken, was mir relevant erschien. Ich weiß aber auch nicht, nach was ich suchen soll.
Gruß, Christian
Hallo,
ich habe in vbox 4.2.0 unter OpenSUSE 12.2 64 Bit ein siduction razorqt 64 Bit laufen, die Gasterweiterungen sind installiert. Mein PC hat nun auch 8 GB Ram, so dass ich der VM großzügig 2 GB Ram spendiert habe.
Da stürzt nichts ab und siduction geht ab wie eine Rakete.
Viele Grüße,
Holger
Edit agaida: http://www.siduction.org/index.php?name=PNphpBB2&file=download&id=191 - dat Bild - kann es sein, dass unser Forum .jpeg nicht mag? Steht jedenfalls so in dem Link über "Filename"
Offtopic: Warum ist denn jetzt das Bild schon wieder "Forbidden You don't have permission to access /modules/PNphpBB2/files/bildschirmfoto1_149.jpeg on this server"? Sowohl mit siduction.org als auch mit www davor.
ich kann es nicht mal anklicken ... kein link ??
Hallo Susan, hallo @reddark,
ich habe auch keinen klickbaren Link mehr.
Viele Grüße,
Holger
Quote from: "holgerw"Hallo,
ich habe in vbox 4.2.0 unter OpenSUSE 12.2 64 Bit ein siduction razorqt 64 Bit laufen, die Gasterweiterungen sind installiert. Mein PC hat nun auch 8 GB Ram, so dass ich der VM großzügig 2 GB Ram spendiert habe.
Da stürzt nichts ab und siduction geht ab wie eine Rakete.
bezieht sich das auf das allgemeine verhalten? ich habe das problem ja bei einem ganz bestimmten vorgang.
ich verwende vbox 4.1.18.
spasseshalber habe ich noch eine maschine mit siduction razor-qt32 erstellt. wiederum, das gleiche problem.
um mir zu beweisen, dass ich nicht doof bin, habe ich einige weitere maschinen mit debian-ähnlichen OS installiert.
Ubuntu 12.04-32_mini.iso
ubuntu-12.10-beta2-server-i386.iso
linuxmint-13-cinnamon-dvd-32bit.iso
ich habe mir jeweils gleich nach der installation eine for-schleife geschrieben. da kann ich hundertmal apt-get update ausführen. das klappt auch, wie es normalerweise zu erwarten wäre.
irgendwie komisch, weil diese OS ja recht ähnlich sind und sich vermutlich auf dieser Ebene (apt-get) kaum unterscheiden dürften.
Aber so ist meine Erfahrung.
Gruß, Christian
moin,
bin der sache jetzt ein ganzes stück näher gekommen.
ftp://ftp.spline.de scheint der übeltäter zu sein.
im original steht in /etc/apt/sources.list.d/siduction.list
Quotedeb ftp://ftp.spline.de/pub/siduction/siduction unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/siduction unstable main
deb ftp://ftp.spline.de/pub/siduction/fixes unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/fixes unstable main
ändern auf
Quotedeb ftp://ftp.spline.de/pub/siduction/base unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/base unstable main
deb ftp://ftp.spline.de/pub/siduction/extra unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/extra unstable main
deb ftp://ftp.spline.de/pub/siduction/fixes unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/fixes unstable main
gemäß siduction-homepage bringt nichts.
jedoch gibt
Quotedeb ftp://ftp.uni-stuttgart.de/siduction/base unstable main
#deb-src ftp://ftp.uni-stuttgart.de/siduction/base unstable main
deb ftp://ftp.uni-stuttgart.de/siduction/extra unstable main
#deb-src ftp://ftp.uni-stuttgart.de/siduction/extra unstable main
deb ftp://ftp.uni-stuttgart.de/siduction/fixes unstable main
#deb-src ftp://ftp.uni-stuttgart.de/siduction/fixes unstable main
die lösung. kein absturz mehr.
Soweit ich das bis jetzt überblicke, ist das problem für mich gelöst. das andere hlabe dutzend test-VMs werde ich auch nochmal testen, jetzt habe keine zeit und lust mehr dazu.
Gruß, C
Quote from: "spacepenguin"Offtopic: Warum ist denn jetzt das Bild schon wieder "Forbidden You don't have permission to access /modules/PNphpBB2/files/bildschirmfoto1_149.jpeg on this server"? Sowohl mit siduction.org als auch mit www davor.
Siehe die Erläuterung im Ursprungspost.
Hallo,
was sagt eigentlich die Geschäftsleitung zu dem von mir beschriebenen Phänomen?
Das ist schließlich nicht normal und auch nicht ok.
Aus irgendeinem Grund verhält sich der spline-Server anders als bspw. der Stuttgarter Server.
(das Beschriebene ist bei mir nach wie vor reproduzierbar.)
Grüße, Christian
Wessen Geschäftsleitung?
Quote from: "agaida"Wessen Geschäftsleitung?
Hallo Alf,
ist doch klar, damit kann doch nur Herr Thommes gemeint sein, aber vielleicht können wir leitenden Angestellten auch schon was dazu sagen ;-)
Sorry @cas, ich musste über Deinen Kommentar und Alfs Frage darauf doch lachen und konnte mir diesen Beitrag nicht verkneifen, ist nicht böse gemeint :-)
Spaß beiseite: Ich werde das auch mal testen und dann berichten.
Viele Grüße,
Holger
Ich kann das Verhalten mit einer schon etwas betagten xfce-installation bestätigen. Nur ne Vermutung von mir: Die Buben haben was gegen "Download-Spammer" (ein dööferes Wort fällt mir dazu nicht ein).
Vermutung:
Wenn ich nur begrenzte Ressourcen hätte, dann würde ich auch knallhart bestimmten Rechnern beim n. Saugen innerhalb eines bestimmten Zeitrahmens den Hahn zudrehen und eventuell sogar die Connection kappen. Könnte ja auch ein Vorbote einer denial-of-service-Attacke sein. Wenn jetzt apt-get update daraufhin klaglos den Dienst einstellt und die VM mit sich reisst, dann sind das Fehler von a) apt-get update oder b) virtualbox. In Fall a) wird sich DonKult über einen aussagefähigen Bugreport sehr freuen, in Fall b) sicherlich oracle. Ich sehe da momentan nichts wirklich weltbewegendes drin, was mich veranlassen würde, alles andere stehen und liegen zu lassen. Einer Vermutung werde ich aber noch nachgehen:
Ich mach das Spielchen mal mit aptitude. und dann mach ich das Ganze noch mal mit ca. 5min zwischen den einzelnen Versuchen. Bisher ging die VM reproduzierbar nach dem 4. Versuch aus.
Update: Der macht auch bei aptitude pünktlich im 4. Versuch die Maschine dicht und aus. Wer viel Spass in den Backen hat, kann das ja mal auf einer realen Maschine probieren. Und zeitversetzt mit ca 20min Abstand. Ansonsten sehe ich da erst mal keinen unmittelbaren Handlungsbedarf.
ich weiss jetzt wenigstens zur Haelfte, warum mir das nie passiert ist: ich bin mit dem Stuttgarter mirror unterwegs...
trotzdem verdient das eine genauere Recherche.
Ich werd mal die Jungs von Spline im IRC dazu befragen.
greetz
devil
Hallo,
na das ist ja ein Fehler, der zuverlässig reproduzierbar ist.
Nach dem vierten Durchlauf von apt-get update stürzt mit dem Spline Spiegel bei mir die Virtualbox auch ab.
Viele Grüße,
Holger
Entweder devil hat im spline-irc schon 'ne schnelle Änderung bewirkt, oder das tritt nicht auf wenn durch mitloggende Prozesse das ganze verlangsamt wird. Ich wollte mit strace mal gucken, ob zum Absturzzeitpunkt auf dem lokalen System noch ne Meldung eingfangen wird. Mein
strace -o spline.log -f apt-get update läuft jetzt zum achten Mal über den spline-Mirror, kein Absturz aber quälend langsam. Jetzt lasse ich deren "begrenze ressourcen" mal besser wieder in Ruhe...
Ich werde da erst heute abend Ansprechpartner finden, also noch nichts passiert.
greetz
devil
Ahoi,
ich habe heute nacht und eben gerade den spline-server nochmal getestet. und siehe da, es gab KEINE probleme. nach jeweils 40 Versuchen habe ich abgebrochen. für praktische zwecke sollte das wohl ausreichend sein ;)
ich hatte aber schon geschrieben, dass mir die VM auch schon mehrfach nach jeweils zwei update's abgeraucht war, was nun wirklich nicht hinzunehmen ist.
Ein weiteres Phänomen beim spline-Server ist, dass er manchmal "Gedenkpausen" einlegt.
tja, schon komisch.
Christian
Ich hab dann heute auch ein wenig getestet. Ergebnis:
* Das Abschmieren tritt nur mit VirtualBox auf. KVM und reale Maschinen sind ok. Von daher ist das Problem zwar ärgerlich, aber nicht tragisch.
* Bei ftp traten manchmal Verbindungsfehler auf (kann passiven socket nicht lesen). Dann wird der halt nicht gelesen, who cares. Das sollte eine Maschine nicht beeinflussen. Macht es auch nicht, ausser bei VBox.
* auch andere Mirror zeigten ähnliches bescheuertes Verhalten. Z.B. unser brasilianischer Mirror. Den hab ich allerdings nicht mit VBox getestet, das war ein Problem aus dem IRC, bei dem es hauptsächlich um Laufzeiten ging.
Die Lösung war ein anderes Protokoll. http:// statt ftp://. Und siehe da, Performance in einem Fall stimmte wie von Geisterhand, auf einmal schmierte die VirtualBox mit Spine auch nicht mehr ab. Da mich diese Sache jetzt insgesamt 8 Stunden von Zeit, die ich eh nicht habe, gekostet hat, kann ich nur empfehlen, das http-Protokoll zu nutzen. Für das neue Release prüfen wir auch ein Für und Wider der ausschließlichen http-Nutzung.
Da die Umstellung auf http mehrere an sich nicht nachvollziehbare Problem schlagartig löste, ist das meines Erachtens der Weg, den wir gehen sollten.
Hier http://packages.siduction.org/ werden doch eh schon http-Adressen empfohlen....
Stimmt. Das ist nicht nur empfohlen. Das ist das einzige Protokoll, auf das unser Repo horcht. Nur bei unseren Spiegeln sah und sieht das anders aus. Und wenn es dann Probleme, warum auch immer mit dem Transport über ftp:// gibt, ist man eventuell dazu angehalten, das Protokoll zu wechseln.
Die Sache hat nur einen Haken: Das muss an verschiedenen Stellen gemacht werden - Im Forum (Downloads), im Manual, in der Konfiguration von pyfll. Und man ist sehr gut damit beraten, so eine Änderung, wenn sie denn sinnvoll ist, an allen Stellen des Auftretens konsistent durchzuführen.
Ich weiß nicht ob das nicht auch ein bischen overkill ist, FTP grundsätzlich zu deaktivieren, es funktioniert ja meistens. Es würde doch eigentlich reichen wenn man kommuniziert und an entsprechenden stellen auch vermerkt, dass HTTP sich als verlässlich(er) erwiesen hat und bei problemen mit FTP eben gewechselt werden sollte.
BTW, ich nutze nun seit es (hier im forum?, erinnere mich nicht mehr) angeregt wurde
deb http://http.debian.net/debian sid main contrib non-free
das funktioniert bei mir seitdem ohne probs, schnell mit dem jeweils aktuellsten und best erreichbaren mirror (meist, aber eben nicht zwingend immer den secondary mirror an meinem wohnort, den ich, weil er eben nicht immer hochaktuell ist, nicht in der sources.list festgenagelt hatte).
Dies (http.debian.net) sollte stärker als beste default einstellung promotet werden. Da hat doch spline eigenlich ausgedient. Und das FTP problem wird ganz nebenbei erschlagen ... :wink:
ich habe bei virtualbox.org mal ein ticket erstellt.
mal sehen, was die dazu sagen.
https://www.virtualbox.org/ticket/11061
gruß, christian
Quote
Da hat doch spline eigenlich ausgedient. Und das FTP problem wird ganz nebenbei erschlagen ...
und unsere repos?
greetz
devil
upps, da war ich mit der lösung schneller als mit der problemerfassung :wink:
michaa7: Es geht auch nicht um die Deaktivierung, sondern um dien Nutzung. Ich drück es mal vorsichtig aus: In meinen Augen hat sich ftp überholt und sollte nicht mehr verwendet werden. Einzige Ausnahme: sftp, was aber schon wieder eine gaaaanz andere Implementation ist. ftp würd ich schon fast in Richtung telnet schieben wollen.
Aber doch schon beunruhigend, dass nur wegen einer Netzanwendung virtualbox abstürzt ...
Wenn Architekten ihre Bauten so planen und umsetzen würden wie Softwareentwickler, dann würde im Zweifel ein Specht genügen, um ganz Berlin zum Einsturz zu bringen.
Quote from: "agaida"Wenn Architekten ihre Bauten so planen und umsetzen würden wie Softwareentwickler, dann würde im Zweifel ein Specht genügen, um ganz Berlin zum Einsturz zu bringen.
Hallo Alf,
dann möchte ich mal hoffen, dass Gilles Caulier nicht am Eifelturm nachbessert :-)
Viele Grüße,
Holger