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!
PS: Meine Timeshift Einstellung liegt auf Boot
Schau doch mal in die /var/log/syslog was er da so macht.
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?
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
> ...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.
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.
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.
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.
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.