Forum: PC Hard- und Software Linux Mint braucht manchmal lange zum runterfahren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von flipchartfresser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
erstmal zu den Daten meines Systems: ich habe Linux Mint 19 Cinnamon.
Normalerweise braucht Mint 10 bis 15 Sekunden zum runterfahren. Manchmal 
braucht er aber auch mal 2 min (geschätzt), dazwischen gibt es nichts. 
Ich habe schon überlegt, ob es vielleicht an Timeshift liegt, das noch 
ein Backup macht, wisst ihr, wie ich das rausfinden kann?

Schonmal vielen Dank für die hoffentlich kommenden Tipps!

von flipchartfresser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
PS: Meine Timeshift Einstellung liegt auf Boot

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
Schau doch mal in die /var/log/syslog was er da so macht.

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Linux versucht beim Shutdown alle laufenden Prozesse zu stoppen, d.h. 
die bekommen ein SIGTERM-Signal. Das ist eine Aufforderung an den 
Prozess, sich zu beenden. Wenn sich ein Prozess aber aus irgend einem 
Grund aufgehängt hat, reagiert er nicht auf das Signal. Das System 
wartet dann für eine gewisse Zeit und schießt den Prozess dann ab, d.h 
er wird aus der Scheduler-Liste gelöscht und evtl. noch geöffnete 
Devicehandles geschlossen. Der Timeout ist mitunter recht lange.

Stellt sich natürlich die Frage, welcher Prozess sich weggehängt hat und 
warum. Das könnte im syslog stehen, wie Andreas B. geschrieben hat. Ich 
habe das Problem manchmal auch bei Ubuntu, wenn ich mit einem 
PIC-Programmer am USB gearbeitet habe. Irgendwas schießt sich dann im 
USB-Subsystem ab und das Runterfahren dauert Minuten.

von Max707 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das läßst sich aber einfach heraus finden indem man genau protokolliert 
was mit dem Pc alles gemacht wurde. Es kann eventuell aber langwierig 
werden.

von Olaf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Schonmal vielen Dank für die hoffentlich kommenden Tipps!

Tja, bedank dich beim duemmeren Teil der Menschheit. Frueher hat Linux 
beim rauf und runterfahren immer angezeigt was es macht. Da haettest du 
sofort ablesen koennen was abgeht. Aber heute soll ja alles huebsch und 
dekadent aussehen.
Du kannst probieren beim rauf/runterfahren mal ESC zu druecken. Dann 
wird bei dir hoffentlich die Textausgabe wieder eingeschaltet.

Olaf

von Fritz B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Du kannst probieren beim rauf/runterfahren mal ESC zu druecken. Dann
> wird bei dir hoffentlich die Textausgabe wieder eingeschaltet.

...oder eben in die syslog schauen ;-)

von flipchartfresser (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Danke für eure Tipps. Werde ich beute Abend mal ausprobieren.

Olaf schrieb:
> Aber heute soll ja alles huebsch und
> dekadent aussehen.

Das haben die bei mir aber ordentlich verkackt ;-) Bei mir wird das Logo 
immer verzerrt dargestellt :)

von T.roll (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Olaf schrieb:
> Tja, bedank dich beim duemmeren Teil der Menschheit. Frueher hat Linux
> beim rauf und runterfahren immer angezeigt was es macht. Da haettest du
> sofort ablesen koennen was abgeht. Aber heute soll ja alles huebsch und
> dekadent aussehen.

Kleiner Troll.

/etc/default/grub öffnen

Hier:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
die Werte ändern auf: nosplash oder noplymouth

von flipchartfresser (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
T.roll schrieb:
> /etc/default/grub öffnen
>
> Hier:
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
> die Werte ändern auf: nosplash oder noplymouth

Klingt gut, wo liegt denn der Unterschied zwischen nosplah und 
noplymouth?

von Andreas B. (bitverdreher)


Bewertung
1 lesenswert
nicht lesenswert
flipchartfresser schrieb:
> T.roll schrieb:
>> /etc/default/grub öffnen
>>
>> Hier:
>> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
>> die Werte ändern auf: nosplash oder noplymouth
>
> Klingt gut, wo liegt denn der Unterschied zwischen nosplah und
> noplymouth?

Seit der Einführung von Plymount heißt der Parameter noplymouth statt 
nosplash. Das dürfte bei allen neueren Systemen so sein.
Aber ob ein durchrauschender Text so sinnvoll ist? Ich schaue mir lieber 
die syslog in Ruhe an.

: Bearbeitet durch User
von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> ...oder eben in die syslog schauen ;-)

Klar, aber dann musst du halt einen Berg Meldungen durchlesen und 
ueberlegen welche es denn sein soll.

Wenn er dagegen beim runterfahren einfach 2min an einer Stelle steht 
dann liesst du ganz entspannt was in der Zeile steht und weisst sofort 
bescheid.

> /etc/default/grub öffnen

Ich weiss das. Aber ich dachte mit so komplexen Dingen kann man nicht 
jedem kommen. Zumal es ja auch an unterschiedlichen Stellen im System 
stehen kann.

Olaf

von T.roll (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Aber ich dachte mit so komplexen Dingen kann man nicht
> jedem kommen. Zumal es ja auch an unterschiedlichen Stellen im System
> stehen kann.

So kompliziert ist das jetzt auch nicht. Und Mint ist ein 
Ubuntu-Abklatsch, weshalb der Pfad passend ist.

von M. K. (kichi)


Bewertung
0 lesenswert
nicht lesenswert
Mir passiert das oft beim Herunterfahren wenn ein wieauchimmer 
(NFS,SMB,etc.) verbundenes Netzlaufwerk nicht mehr verfügbar ist. Dann 
wartet er erst n*1m30s und versucht das Laufwerk zu trennen. Ich nutze 
zwar kein Mint (mehr), aber das Problem hatte ich bereits mit Arch, 
openSUSE und ubuntu.

von flipchartfresser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal geguckt,die syslogs sind aber zu unübersichtlich. Timeshift 
hat im November noch gar keine Backups gemacht. Ich nehme an,dass es 
daran liegt,dass er die virtuellen Maschinen mitsichert, der Platz (64 
GB Stick) schlichtweg nicht reicht.
Werde das mal umstellen und euch dann berichten.

PS:Das mit Escape funktioniert, wenn es also nochmal passiert, werde ich 
mal gucken.

von Eric (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass Linux neben Windows installiert ist?

Wenn dem so ist, deaktiviere unter Windows das quickboot oder fastboot 
oder wie die es nennen.

Denn zumindest vom Kernel 4.8 sind mir da ein paar Probleme bekannt.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich systemd mit seinem berüchtigten "a stop job is running".

Das gabs früher nie, da hat einfach alles nur reibungslos funktioniert. 
Aber seit die systemd-Seuche sich ausgebreitet hat sind solche Probleme 
an der Tagesordnung.

von Logger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Klar, aber dann musst du halt einen Berg Meldungen durchlesen und
> ueberlegen welche es denn sein soll.
>
> Wenn er dagegen beim runterfahren einfach 2min an einer Stelle steht
> dann liesst du ganz entspannt was in der Zeile steht und weisst sofort
> bescheid.

Deswegen haben die Meldungen Zeitstempel in den Logs.

von Logger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Das gabs früher nie, da hat einfach alles nur reibungslos funktioniert.
> Aber seit die systemd-Seuche sich ausgebreitet hat sind solche Probleme
> an der Tagesordnung.

Das gab/gibt es auch mit SYSV Init.

von Eric (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Bernd K.
Ich bin auch kein Freund von systemd.
Aber ich hatte auf einem System auch mal eine ähnliche Situation. Das 
lag an dem quick/fastboot von Windows.
Deaktiviert war der Fehler behoben.

von Eric (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@all
Und nein, der Fehler taucht in den Logs nicht auf. Aber er tritt 
zusammen mit einem BERT Fehler beim runterfahren auf

von Bert? (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie genau?

von Glaskugel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eric schrieb:
> Aber er tritt
> zusammen mit einem BERT Fehler beim runterfahren auf

Meine Glaskugel sagt mir das R42 auf dem Mainboard defekt ist.

von Eric (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Nein. Bert hat mit dem Speicher zu tun. Dieser Fehler stört das 
Runterfahren nicht.
Der eigentliche Fehler ist ein anderer, hat mit den gemounteten LW zu 
tun. Ich such ihn am Wochenende mal raus. Hierzulande hat es jetzt Abend 
und ich hab Anderes zu tun.

Wie gesagt, falls Dualboot mit Windows einfach mal das fast/quickboot 
abstellen und die Sache sollte gelöst sein.
Auch die Zeit von 2 Minuten spricht dafür.

von flipchartfresser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nein, ich habe kein Multiboot mit Windows, nur in einer virtuellen 
Maschine ist das installiert.

von o. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eric schrieb:




>
> Wie gesagt, falls Dualboot mit Windows einfach mal das fast/quickboot
> abstellen und die Sache sollte gelöst sein.

Was sollte der damit zu tun haben?

>>> lange zum runterfahren


das mit dem loggen ist auch so eine Sache, endet spätesten mit dem 
syslogger nur ist die show dann noch nicht vorbei man zeige ein logfile 
vor welches die Nachricht system halted enthält ;)

@Fragesteller

Kenne ubuntdian äh sorry linuxmint nicht, aber mach halt mal folgendes 
beende X und mach keinen shutdown sondern ein halt (also ohne poweroff) 
dann kannst du dir das alles ansehen. Was man einem systemdd da sagen 
muss weis ich leider nicht.


abgesehen davon erhälst du in einem passenden linuxmint-Forum vermutlich 
bessere Hilfestellung.

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
flipchartfresser schrieb:
> Nein, ich habe kein Multiboot mit Windows, nur in einer virtuellen
> Maschine ist das installiert.

bei mir in der Firma hab' ich den Spass auch. Debian Stretch in einer 
VirtualBox unter Win7. Das Problem tritt nicht immer auf.
Mit "sudo dmesg" kannst du mal gucken, ob nach dem hochfahren was faul 
ist, dann auch mal die Meldung beim runterfahren in Tante Gockel 
eingeben. Das Problem tritt wohl bei vielen auf...
Loesung habe ich aber auch keine, keine Zeit zum suchen momentan...

von Gerhard Zintel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hier mal eine Möglichkeit den Timeout runter zu setzen falls es ein Stop 
Job Problem von systemd ist:
https://forum.siduction.org/index.php?topic=6074.0

Die entscheidende Stelle:
  Du kannst auch in /etc/systemd/system.conf den Wert für
  Code: [Select]
  DefaultTimeoutStopSec=90s
  runterrsetzen


Oder google dafür nach: DefaultTimeoutStopSec

Gerhard

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.