Linux Mint braucht manchmal lange zum runterfahren

PS: Meine Timeshift Einstellung liegt auf Boot

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.

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.

> 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

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 ;-)

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 :)

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

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?

> ...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

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.

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.

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.

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.

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.

@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.

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

Wie genau?

Eric schrieb:
> Aber er tritt
> zusammen mit einem BERT Fehler beim runterfahren auf

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

@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.

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

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.

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...

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