Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
kB schrieb: … erwischt er den Virtualisierer.
Das ist ja schon mal cool, danke. (Ich bin immer wieder begeistert, wie ein "altes" Betriebssystem (Unix) so viel mehr und besser kann als ein "topmodernes" (Windows).) Allerdings verwirrt mich das eher noch mehr, denn einen solchen Fehler in Virtualbox kann man wohl ausschließen, der wäre sonst sicherlich bekannt, und wie angegeben nutze ich im schlimmsten Fall 46 GB für die VMs plus Hostsystem von 64 GB des Rechners. Ich orakele mal: Ist es denkbar, dass ich ein Hardwareproblem mit dem Speicher habe, dass der sozusagen "nach und nach ausfällt" und somit dann doch knapp wird:
Die Kiste hat 4 * 16 GB, wenn also ein Riegel "ausfällt", könnte der Speicher ja doch knapp werden, wenn zwei ausfallen, wird es definitiv zu eng. Falls das eine mögliche Ursache ist, dass das System also plötzlich "Speicher verliert" bzw. weniger zur Verfügung hat, geht das überhaupt im laufenden Betrieb? Wenn ja, könnte ich das in einem Protokoll sehen?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Emma2 schrieb: […] einen solchen Fehler in Virtualbox kann man wohl ausschließen
Dafür sehe ich kein Indiz. Eine Speicheranforderung in einer Endlosschleife killt mit Sicherheit jedes System, es ist nur eine Frage der Zeit. Virtualbox muss nicht der Schuldige sein, sondern ist das Opfer.
Die Kiste hat 4 * 16 GB, wenn also ein Riegel "ausfällt", könnte der Speicher ja doch knapp werden, wenn zwei ausfallen, wird es definitiv zu eng.
Bein einer solchen Vermutung wäre doch ein umgehender und umfangreicher Speichertest logisch, oder?
Falls das eine mögliche Ursache ist, dass das System also plötzlich "Speicher verliert" bzw. weniger zur Verfügung hat, geht das überhaupt im laufenden Betrieb?
Natürlich geht das grundsätzlich.
Wenn ja, könnte ich das in einem Protokoll sehen?
Natürlich. Bei einem geordneten Lockdown endet das Systemlog mit solchen Zeilen:
Mär 15 20:12:46 systemd[1]: Reached target Power-Off.
Mär 15 20:12:46 systemd[1]: Shutting down.
Mär 15 20:12:46 systemd-shutdown[1]: Syncing filesystems and block devices.
Mär 15 20:12:47 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Mär 15 20:12:47 systemd-journald[279]: Journal stopped Wenn diese fehlen, ist der Kernel oder der Init-Prozess abgestürzt.
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
verstellt zu haben außer Speichergeschwindigkeit
Wie soll man das verstehen, mit den proprietären OC Tools des Gaming MBs gespielt? Egal, danach hört es sich hier eigentlich nicht an. Obwohl stabile defaults auf einem Server natürlich Sinn machen ... Die Ramverteilung ist bei VBox ja statisch, also einfach mal die Ramentwicklung beobachten. USB würde ich aber auch mal angehen. Schnittstelle überlastet? USB mußt du vor Ort klären, deaktivieren ist immer gut.
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
kB schrieb: Virtualbox muss nicht der Schuldige sein, sondern ist das Opfer.
Ok, hatte ich falsch verstanden. Dann wird vielleicht der "dickste Brocken" aus dem Speicher geräumt. kB schrieb: Bein einer solchen Vermutung wäre doch ein umgehender und umfangreicher Speichertest logisch, oder?
Ja, will ich tun... nur muss ich jetzt erstmal gucken, wieso in meinem GRUB-Menü kein memtest+ drin steht... kB schrieb: Natürlich. Bei einem geordneten Lockdown endet das Systemlog mit solchen Zeilen:
Mär 15 20:12:46 systemd[1]: Reached target Power-Off.
Mär 15 20:12:46 systemd[1]: Shutting down.
Mär 15 20:12:46 systemd-shutdown[1]: Syncing filesystems and block devices.
Mär 15 20:12:47 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Mär 15 20:12:47 systemd-journald[279]: Journal stopped Wenn diese fehlen, ist der Kernel oder der Init-Prozess abgestürzt.
Ja, dann ist er (gestern) wohl abgestürzt:
Die letzten Einträge, die ich mit journalctl -b -2 erhalte sind "sehr viele"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 | Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:50 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:01:51 svh-dev kernel: usb 1-10: reset high-speed USB device number 2 using xhci_hcd
|
Muss ich mal nachlesen, ob ich dazu etwas finde. Danke bis hier. Ich werde nun mal das BIOS aktualisieren, wenn es ein neueres gibt, und einen memtest+ durchzuführen versuchen. Melde mich danach wieder.
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Vielleicht ist ja das amoklaufende USB-Teil zumindest ein Grund für meinen volllaufenden Speicher, aber leider bin ich nicht so super-firm in Hardware und schon gar nicht in ihrer Ansteuerung aus Ubuntu heraus. Deshalb bitte ich nochmal um einen Rat:
Sollte ich das einmal probieren: https://forum.ubuntuusers.de/topic/fehler:-reset-high-speed-usb-device-alle-paar/? Oder kann das "schaden"? Ach so, mein "device number 2" ist dieses
| Bus 001 Device 002: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader)
|
... das würde ja zu dem Thread aus 2008 (!) passen... ... außer dass es bei mir die Datei /etc/modprobe.d/usb-core-options nicht gibt. ☹
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Da ich an diesem Server sicher keine Speicherkarten lesen oder schreiben will, könnte ich das Gerät ja am liebsten deaktivieren (um mir das Ausbauen zu ersparen), finde aber sehr viele unterschiedliche Beschreibungen für diese Aktion. Gibt es eine newbie-taugliche Beschreibung, ein einzelnes USB-Gerät zu deaktivieren? Oder sollte ich doch besser die Hardware ausbauen?
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
um mir das Ausbauen zu ersparen
Reicht nicht "Stecker ziehen", wo ist dein Problem ? Wieso läßt Du solche Komponenten in einem Server überhaupt "mitlaufen" ?
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
hakel2020 schrieb: Wieso läßt Du solche Komponenten in einem Server überhaupt "mitlaufen" ?
Ich habe mir - zugegeben - darüber keine Gedanken gemacht. Aber ok, Steckerziehen ist eine Möglichkeit. Werde ich tun und dann berichten.
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Oh, der Fehler hatte wohl nicht so wirklich mit dem USB-Port zu tun, denn jetzt sieht es anders "seltsam" aus:
Ich lasse seit dem letzten Start meinen Webmin geöffnet und hatte bis gestern etwa 43% des Speichers belegt. Aber heute morgen waren es plötzlich 71%. Also habe ich mich per SSH angemeldet und meine VMs überprüft - von denen liefen anscheinend nur zwei Stück. Ich habe deshalb die anderen VMs neu gestartet, damit stieg die Speicherbelegung aber auf 85% 😳 Nun habe ich wieder in den Webmin geguckt, und dort sieht es so aus, als liefen einige VMs zwei Mal - aber das kann ja wohl kaum sein, oder?
- Bilder
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
Das hört sich doch "gut" an, da bist du der Sache auf de Spur. 👍 Ich würde empfehlen, du machst diesen Thread zu und eröffnest einen neuen Thread unter Serverdienste. Da gibt es bestimmt Leute die Erfahrung mit Webmin haben, und warum man es unter Ubuntu nicht nutzen sollte.
aber das kann ja wohl kaum sein, oder?
top, htop, ps - das kann man doch wohl prüfen ... Hmm ... hört sich jetzt irgendwie nach einem Konfigfehler an.
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Zumindest das aktuelle Problem könnte eventuell ein Fehler auf meiner Seite zu sein: Zum Start melde ich mich per SSH auf dem Host an und starte die VMs, danach schließe ich die Konsole mit Strg+D. (Grundsätzlich wundere ich mich, wieso die VMs dann überhaupt weiterlaufen, habe aber darauf bisher keine Antwort erhalten.) Das Herunterfahren, Sichern und Neustarten geschieht als Cronjob für den selben Benutzer, mit dem ich die VMs gestartet habe, aber es scheint so, als würden die laufenden VM-Prozesse "aus dem Cronjob heraus" nicht gesehen. Und besonders seltsam für mich ist, dass dieser Effekt nur auf einem von drei Hosts auftritt. Alle diese drei Hosts sind gleich installiert und konfiguriert (ich habe die alle "in einem Rutsch" eingerichtet). Der gravierendste Unterschied zwischen den Hosts ist, dass der mit dem "Problem" der einzige mit AMD-Prozessor ist - aber das kann ja wohl wirklich nicht der Grund sein, oder etwa doch? p.s.: Die VMs laufen wirklich, sind nur nicht in dem neu geöffneten SSH sichtbar. Kann oder muss ich irgendwie "manuell" die "Verbindung" zu ihnen herstellen? (Hoffe, die Frage war jetzt nicht zu wirr...)
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
hakel2020 schrieb: Hmm ... hört sich jetzt irgendwie nach einem Konfigfehler an.
Klassischen "Konfigfehler" würde ich eher ausschließen, wahrscheinlich ist es eher ein Verständnisproblem bei mir bezüglich User, Kontext und Prozessen. Nochmal zur Erläuterung: Die VMs laufen, ich "sehe" sie nur in neu geöffnetem SSH nicht. (Eventuell habe ich letzte Woche so den Hänger provoziert, weil ich sie einfach nochmal gestartet habe.) Das Problem scheint zumindest aktuell genau dieses zu sein. Meine Fragen sind deshalb:
Wieso laufen die VMs überhaupt weiter, wenn ich die SSH mit Strg+D schließe? Was ist der bessere Weg, sie zu starten, und zwar (a) einige automatisch zusammen mit dem Host und (b) manche manuell? Wie kann ich mit einer neuen SSH (oder noch wichtiger: mit meinem Cronjob) diesen "Kontext" wieder öffnen?
(Ist das eine neue Frage? Dann mache ich einen neuen Thread draus, dachte jedoch, das ist noch das selbe Thema.)
(Und, nein, Webmin ist nicht der Übeltäter, ich "mache" auch nichts mit dem, sondern nutze ihn nur zum Gucken.)
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Da ich ja noch immer nicht so ganz firm bin mit Linux und nicht ganz genau weiß, was Strg+D im SSH macht, habe ich es auf meinem lokalen Rechner ausprobiert (ist allerdings ein Mint 19.3). Nach allem, was ich bisher gelesen habe, macht Strg+D das gleiche wie exit, meldet mich also ab. Korrekt?
Ich habe nun per Strg+Alt+F1 ein Terminal geöffnet, eine lokale VM gestartet und mich dann "abgemeldet". Selbst nach Anmeldung auf einem "anderen" Terminal mit Strg+Alt+F2 ist die laufende VM dann sichtbar, wird mir also mit vboxmanage list runningvms angezeigt. Wie also kann es dann sein, dass auf dem einen Host (und zwar nur auf dem "mit AMD") genau das nicht der Fall ist? Es gibt VMs, die "gehören" meinem User "localadmin", aber in einer neu aufgemachten SSH für diesen User sehe ich diese VMs nicht. Das macht mich misstrauisch. Was könnte diesbezüglich denn überhaupt "falsch konfiguriert" sein? Hintergrund: Ich habe alle Hosts "gleich konfiguriert". Das geht so weit, dass ich nach dem Basis-Ubuntu mich per SSH dorthin verbunden und alle weiteren Befehle per Copy&Paste eingegeben habe. Es sollte also keine echten Unterschiede zwischen den drei Hosts geben... ("solte, sollte, Fahradkette"... oder so ähnlich 😉 )
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Neue Erkenntnis:
Offenbar gehen VMs, die als "headless" (ohne GUI) gestartet werden, in den Besitz des Prozesses VBoxHeadless über, und deshalb laufen sie weiter, auch wenn ich die SSH schließe. Meine Frage ist damit beantwortet... und die Anschlussfrage stelle ich wie gewünscht in einem neuen Thread. Danke an alle!
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
und nicht ganz genau weiß, was Strg+D im SSH
SSH ist nur ein Protokoll mit dem man eine Fernverbindung herstellt. Wenn du die Leitung "kappst", ist das den laufenden Prozessen egal. Wäre ja auch schlimm, wenn nicht. starvm und poweroff sind die Befehlsoptionen für VBoxManage. Egal, vielleicht verstehe ich deine Probleme nicht. Immer etwas schwierig aus der Ferne! 👍
|