Ubuntu macht Probleme wegen zu heißen USB-WLAN-Stick

FatManStanding

Lieutenant
Registriert
Aug. 2021
Beiträge
564
Hallo,

ich hatte seit heute früh Probleme mit all meinen Ubuntus (22.04, 24.04 und jeweils die LiveCDs dazu). Einzelne Programme wie Firefox starteten nicht (im Terminal ohne Meldung), Thunderbird zumindest langsam. Einzelne Netzwerkfreigaben mit AutoFS klappten nicht (z. B. zu meinem Raspberry PI), die zur Fritzbox ging aber. Ich konnte im Terminal journalctl aufrufen, aber keinen reboot durchführen - hier sprang der Prompt einfach zur nächsten Zeile so als würde der Aufruf gleich ausgeführt und nichts passierte. Beide getestete LiveCDs starteten nicht, die blieben beim Ubuntu-Logo hängen. Bei einer habe ich die gleiche Fehlermeldung beim Abbruch des Vorgangs gesehen wie unter dem installierten Ubuntu im Journal:

Code:
echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables thismessage

Hab das gegoogelt und jemand hatte das Problem i.V.m. seinem Netzwerk. Bei mir war es ein USB-WLAN-Stick, der extrem heiß war. Das Metallstück vorn konnte ich nicht anfassen. WLAN-Sticks sind schon oft warm geworden, so extrem hatte ich das noch nie. Der Stick selber wurde in 'lsusb' erkannt, es gab aber ein paar Fehler dazu im Journal

Code:
NetworkManager[887]: <info>  [1744698315.0267] device (wlx001f1fac5284): state change: unavailable -> unmanaged (reason 'unmanaged', sys-iface-state: 'managed')
NetworkManager[887]: <error> [1744698315.0260] device (wlx001f1fac5284): Couldn't initialize supplicant interface: Name owner lost
systemd-udevd[397]: wlx001f1fac5284: Worker [438] failed
systemd-udevd[397]: wlx001f1fac5284: Worker [438] processing SEQNUM=4495 killed
systemd-udevd[397]: wlx001f1fac5284: Worker [438] processing SEQNUM=4495 is taking a long time
NetworkManager[887]: <info>  [1744697751.6941] device (wlx001f1fac5284): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')

Ich hab den Stick ausgesteckt und alles geht wieder. Mich würde interessieren warum ein aus welchem Grund auch immer nicht funktionierender WLAN-Stick das System stört. Der Stick hat keine aktive Verbindung, die läuft aber LAN. Ich hab keine Ahnung warum der angesteckt war.
 
Hast du Ubuntu auf einer SSD installiert?

Was meinst du mit "LiveCDs"?

FatManStanding schrieb:
Mich würde interessieren warum ein aus welchem Grund auch immer nicht funktionierender WLAN-Stick das System stört.
Einen Hinweis gibt das Journal: systemd-udevd[397]: wlx001f1fac5284: Worker [438] processing SEQNUM=4495 is taking a long time

Der Stick steckt, wird vom NetworkManager erkannt, soll initialisiert werden, das klappt nicht, weil kaputt. Das Killen des Prozesses dauert lang, reboot wartet darauf, weil das Standard-Timeout in systemd zu lang ist.

In /etc/systemd/system.conf wirst du sehen, dass DefaultTimeoutStopSec auf 90 Sekunden eingestellt ist.

FatManStanding schrieb:
Ich konnte im Terminal journalctl aufrufen, aber keinen reboot durchführen - hier sprang der Prompt einfach zur nächsten Zeile so als würde der Aufruf gleich ausgeführt und nichts passierte.
Doch, nach 90 Sekunden wäre der reboot durchgeführt worden.
 
  • Gefällt mir
Reaktionen: Aduasen, BFF, fr13del und eine weitere Person
Ja, beide Ubuntus sind auf 2 verschiedenen SSDs installiert. Mit LiveCD ist einfach ein Install-Medium (USB-Stick) gemeint.

Was genau macht dieser Timeout? Ubuntu versucht den Stick zum laufen zu bringen was nicht klappt. Wenn ich dann den shutdown versuche wartet er weitere 90 Sekunden ob der Stick nicht vielleicht dennoch reagiert?
 
SIGTERM wird zum Prozess gesendet, um ihn "ordentlich" zu beenden. Wenn der Prozess nicht reagiert, wird nach einer Timeout-Zeit - bei SystemD standardmäßig eben 90 sec. - SIGKILL gesendet.

Wikipedia: "SIGTERM ist das Standard-Signal, das durch die Befehle kill oder killall an Prozesse gesendet werden kann. SIGTERM leitet die Terminierung eines Prozesses ein, aber anders als das SIGKILL-Signal kann es vom Prozess angenommen und anschließend wahlweise interpretiert oder ignoriert werden. Die Intention ist dabei, dass der Prozess nicht wie mit dem SIGKILL abrupt gestoppt wird, sondern die Möglichkeit hat, notwendige Aufräumarbeiten (Freigeben von Netzwerkports, Schreiben von zwischengespeicherten Daten in Dateien o. ä.) vorzunehmen."

Man kann in der system.conf die Timeout-Zeit verringern.

Edit: gerade bei Fedora geguckt: /usr/lib/systemd/system.conf - dort steht der Timer bei 45 Sekunden.
 
Zuletzt bearbeitet:
Der shutdown hat bei deutlich länger als 90 Sekunden gedauert. Ich hatte schon anderer Situationen wo das laneger gedauert hat. Sieht man das im journal welcher Prozess das verhindert oder ist journalctl da selbst schon inaktiv?
 
Es passiert manchmal auch unabhängig vom hier beschriebenen Problem, dass der shutdown länger dauert. Es wäre manchmal interessant zu wissen woran das liegt. Im journal sehe ich aber meist nicht dazu.
 
Ich denke die gute alte Notabschaltung aller Prozesse und herunter fahren sollte immer noch funktionieren.
Hierfür wird die ganze Zeit Alt + Druck gedrückt gehalten und nacheinander die Tasten R + E + I + S + U + B betätigt.
Wer sich das nicht merken kann, dafür gibt es folgende Gedankenstützen mit den Anfangsbuchstaben:
"Reboot Even If System Utterly Broken"
oder
"Richtig Einparken Ist So Unglaublich Banal"
oder
"busier" rückwärts.
 
@mo schrieb:
die gute alte Notabschaltung aller Prozesse und herunter fahren sollte immer noch funktionieren.
Hierfür wird die ganze Zeit Alt + Druck gedrückt gehalten und nacheinander die Tasten R + E + I + S + U + B betätigt.
Ja, das kenne ich ebenfalls in dieser Art und funktioniert meist auch. Einzig habe ich hier einen Dell Optiplex 9020 USSF mit 8GB RAM unter Mint (siehe Anhang), der sich manchmal aufhängt und sich dann sogar dieser Ausschalt-Option verweigert.

---------

Als nachträgliche Ergänzung noch kurz ein Link, falls jemand weitere Hintergründe zu dieser Notabschaltung wissen mag:
https://de.wikipedia.org/wiki/Magische_S-Abf-Taste
 

Anhänge

  • Bildschirmfoto zu 2025-04-15 18-16-27.png
    Bildschirmfoto zu 2025-04-15 18-16-27.png
    49 KB · Aufrufe: 17
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: @mo
Das nützt mir aber alles wenig. In der Regel sehe ich ja erst, dass das Ubuntu beim herunterfahren länger braucht wenn das ganze schon läuft. Ich möchte gern herausbekommen welcher Prozess daran Schuld war. In dem Fall oben war es der Stick, das passiert aber auch in anderen Konstellationen.
 
Nochmal zurück zu dem stick. Der scheint in der tat defekt zu sein. Ich habe mal nach zu heissen wlan-stick gegoogelt und v.a. Beiträge bis 2015 gefunden. Meine wlan-sticks sind alle schon älter, keine Ahnung wie alt. Kann es sein, dass das ein Problemen alter Sticks ist?
 
@FatManStanding Hatte ich vor Ewigkeiten auch mal, dass ein WLAN-Stick sehr heiß wurde, und anschließend abgekackt ist. Hatte dann einen neuen Stick gekauft, und das Problem war damit behoben.
 
Ich dachte halt weil es Berichte dazu bis ca. 2015 gab sei es ein altes Problem. Ich hab auch einen neuen gekauft.
 

Ähnliche Themen

Zurück
Oben