Debian 9 braucht eine Ewigkeit um herunterzufahren?!? [Gelöst]

[jmar83]

Hallo zusammen

Das läuft jetzt sicher schon 20min:




Weiss jemand, was dieser ver***mte Quatsch soll? Bin nächstens dran das Zeugs aus dem Fenster zu werfen!!

Bin für jegliche Inputs dankbar...

[jmar83]

Ist das alles durch "wlan0" ausgelöst, und was sind "stalls on CPUs/tasks" ?

[bullgard]

Wenn Du schon nach 20 Minuten Fehlersuche "das Zeugs aus dem Fenster werfen" willst, hast Du Dir das falsche Hobby ausgesucht.
Wenn der Fehler noch einmal auftreten sollte, kannst Du versuchen, den Computer mittels der 'magischen SysRq-Taste' auszuschalten. Anschließend den Rechner erneut booten und in den Emergency-Modus fahren.
Im Emergeny-Modus versuchen, den Rechner per Software auszuschalten. Dabei entsteht (mindestens) ein Systemlog mit Einträgen. Auch das Journal, wenn Du systemd verwendest.
Rechner erneut booten. Den Befehl geben:
'# journalctl -k -b -1': Show all kernel logs from previous boot.
Diese Ausgabe in einen Pastebin umleiten und dessen Link hier im Forum posten.
Zusätzlich die Ausgabe von '~$ inxi -F' hier posten.

[DeletedUserReAsG]

Ist das alles durch "wlan0" ausgelöst[…]?¹

Der Stop-Job wurde ja offensichtlich beendet. Die Chancen stehen gut, dass die Kiste schon lange runtergefahren ist, und nur das Ausschalten nicht funktioniert. Ist ein wenig schwierig zu debuggen, weil die Datenträger zu dem Zeitpunkt schon lange ausgehängt sind, und daher keine Logs mehr geschrieben werden. Würde auf eigenständige Informationsbeschaffung und etwas Probieren hinauslaufen – wirf den verdammten Quatsch also besser aus dem Fenster und fang was mit Rosenzüchten oder so an.


¹autodeplenk triggered

[jkoerner]

Moin,
Einstellungen daran kann man unter /etc/systemd/system.conf vornehmen.

Nachdem mir die Warterei zu bunt wurde habe ich die Zeilen
ShutdownWatchdogSec=5s
und
DefaultTimeoutStopSec=5s

auskommentiert und mit Sekunden zeitlich begrenzt. Hat bislang keine negativen Auswirkungen auf irgendetwas.

[jmar83]

Vielen Dank für die Feedbacks!!

Ja, es kann gut sein dass die VM schon heruntergefahren war (jedoch unsauber)... das schliessen (besser gesagt: Abwürgen, ohne ACPI) hat jedenfalls auch nicht mehr gut geklappt, und das VirtualBox-Fenster wurde erst viel später geschlossen nachdem ich auf "x" (Fenster unter Window$ schliessen) geklickt habe... danach hatte die VM auch den Status "abgebrochen"...

Jedenfalls habe ich nun auch den vom Windows 10 zur Debian 9-VM durchgereichte WLAN-USB-Stick entfernt (es hiess ja was von "WLAN0" bei meinem Problem) entfernt... darauf kann ich momentan verzichten, später muss es aber dann wieder rein...

[jmar83]

"wirf den verdammten Quatsch also besser aus dem Fenster und fang was mit Rosenzüchten oder so an."

Grüne Pflanzen wären aber lukrativer!!

[am2]

@jmar83,
So ein Bildschirm wie in deinem Eröffnungspost hatte ich schon einige Male. Irgendwann fiel mir auf, dass in diesen Fällen immer irgenwelche USB-Geräte (meistens externe Festplatten) angeschlossen waren. Seitdem achte ich immer darauf, dass alles sauber ausgehängt und ausgeschaltet ist.

Auch VMs können das Ausschalten negativ beeinflussen, bei mir ist es jedoch sehr selten. Mit den Festplatten habe ich mich dann etwas beschäftigt. Sie haben das Aus öfter gestört aber nicht immer. Da konnte ich nur noch raten und kaufte ein neues USB-Kabel. Danach gab's keine Probleme mehr. Die Festplatten werden trotzdem immer ausgehängt und ausgeschaltet

[jmar83]

Vielen Dank für Dein Feedback. Das EnOcean-Funkmodul (letztendlich ein FTDI USB-RS232-Konverter) hat keine Probleme, der USB-WLAN-Stick mit Ralink-Chipsatz (Heute heisst der Chip-Hersteller "Mediatek", das Produkt an sich heisst "802.11n"-Adapter von Logilink) scheint da eher Probleme zu machen... habe schon verschiedenes Versucht, mit und ohne "Guest Additions"-Treiber, USB 1.1, 2.0, 3.0-Einstellung in VirtualBox etc... scheint alles nix zu bringen.

Des weiteren ist mir auch aufgefallen, dass die in die VM durchgereichten Geräte verschwinden (aus dem Geräte-Manager) beim VM-Start (sollte ja normal ein), aber z.B. der WLAN-Stick beim beenden der VM im Geräte-Manager nicht wieder erscheint. (Im Ggs. zum EnOcean-Funkmodul mit FTDI USB-RS232-Konverter)

An den Kabeln kann es somit beim WLAN-USB-Modul nicht liegen, dort ist ja kein Verlängerungskabel oder so dran.

Die Frage ist nun ein wenig off-topic, aber: Haben die Treiber des VirtualBox-Host-System (in meinem Fall ja Win10) einen Einfluss auf USB-Geräte, welche der Virtual Machine (zur exklusiven Nutzung, also nur durch diese) durchgereicht werden? Denke eher weniger...(?)

(NIC-Treiber z.B. werden wohl ziemlich sicher einen Einfluss haben, aber die NIC ist in meinem Fall auch kein zur exklusiven Nutzung durchgereichtes USB-Gerät sondern sitzt irgendwo auf dem PCIE-Bus...)

[willy4711]

Schön, dass man so "nebenbei" erfährt, das es um ein Gast- Betriebssystem in einem Windows Host geht.
Meinst du nicht, diese Info wäre im Eröffnungspost ganz hilfreich gewesen ?

Der Gast ist ja runter gefahren, was fehlt ist lediglich noch Poweroff.

Wie auch immer -- Ich würde würde versuchen, erstmal das WLAN im Gast zu deaktivieren. (wenn du den Modem Manager installiert hast, sollte
das ja Problemlos gehen)
Hängt es dann immer noch, wäre der zweite Schritt, den WLAN- Stick im Gast zu deaktivieren.

Weitere Möglichkeiten

Code: Alles auswählen

systemctl poweroff

oder

Code: Alles auswählen

systemctl poweroff -i

-i, --ignore-inhibitors
When system shutdown or a sleep state is requested, ignore inhibitor locks. Applications can establish inhibitor locks to avoid that
certain important operations (such as CD burning or suchlike) are interrupted by system shutdown or a sleep state. Any user may take these
locks and privileged users may override these locks. If any locks are taken, shutdown and sleep state requests will normally fail (unless
privileged) and a list of active locks is printed. However, if --ignore-inhibitors is specified, the established locks are ignored and not
shown, and the operation attempted anyway, possibly requiring additional privileges.

[jmar83]

Ich habe an keinem einzigen Punkt der von mir geschriebenen Beiträge das Wort "Gast" gefunden, jedenfalls ergibt die Browser-Suche per Ctrl-F nichts dergleichen...

Windows ist das Virtualisierungs-Host-System, und NICHT der Gast. Ist glaube ich nicht das erste Mal, wo das für Verwirrung sorgt!

Am besten wohl das Wort "Windows" in diesem Forum gar nicht erwähnen, dann gibt's auch keine Verwirrungen diesbezüglich...

[jmar83]

Und der Screenshot sollte ja implizieren, dass es sich eben NICHT um Windows (sondern um ein Linux, genauer Debian) handelt!

[willy4711]

Windows ist das Virtualisierungs-Host-System, und NICHT der Gast. Ist glaube ich nicht das erste Mal, wo das für Verwirrung sorgt!

Schön, dass man so "nebenbei" erfährt, das es um ein Gast- Betriebssystem in einem Windows Host geht.
Meinst du nicht, diese Info wäre im Eröffnungspost ganz hilfreich gewesen ?

Ich bin ja doof, aber hilf mir doch weiter: Ist dein im Eröffnungspost erwähntes Debian ein Gast oder nicht ?

[jmar83]

Klar!

Vielleicht habe ich mich auch ein wenig undeutlich ausgedrückt, im ganzen Arbeits-Stress, muss mich entschuldigen falls ich zu undeutlich war!

Und vielen vielen Dank euch allen für die guten, hilfreichen Tipps - bei Gelegenheit werde ich es anschauen. (Momentan geht's wieder von Task zu Task, jeden Tag wieder eines neues Problem mit höchster Priorität - na ja, kommt ja nicht von mir selbst!! )

[willy4711]

Und wie du sicher bemerkt hast, beziehen sich meine Bemerkungen ausschließlich auf den Gast ( )
Ob es helfen könnte, musst du testen.

[jmar83]

Vielen Dank, werde mal schauen!

[jmar83]

Nochmal vielen Dank für die Beiträge.

Das Problem war die Intel 500-GB-SSD... diese war fabrikneu (habe ich also frisch ausgepackt), war aber entweder

a.) Von Anfang an defekt

oder ging

b.) Erst nach ein paar Tagen oder 1-2 Wochen defekt


Genau lässt sich das nicht mehr sagen, das Problem ist schon seit einiger Zeit gelöst mit einer neuen SSD.