Mein Rechner ist ohne mein Zutun heruntergefahren- Wieso?

[scale7]

Nach dem Aufstehen habe ich festgestellt, dass mein Rechner nicht, wie normalerweise, läuft. Wie kann ich herausfinden, was da passiert ist?
Ich bin nicht besonders vertraut mit dem Umgang mit Logfiles, habe aber mal in /var/log/messages geschaut:

Code: Alles auswählen

Jul 31 18:09:42 debian kernel: [475337.122863] uzbl-core[24229]: segfault at 0 ip 00007f01d6a88e20 sp 00007fffe4e0c2d8 error 4 in libjavascriptcoregtk-1.0.so.0.16.17[7f01d65c6000+6c8000]
Aug  1 06:25:08 debian rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="557" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug  1 12:18:00 debian rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="538" x-info="http://www.rsyslog.com"] start
Aug  1 12:18:00 debian kernel: [    0.000000] Initializing cgroup subsys cpuset

In /var/log/syslog fand ich Folgendes:

Code: Alles auswählen

Aug  1 06:52:01 debian CRON[6094]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ))
Aug  1 07:17:01 debian CRON[10453]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  1 08:17:01 debian CRON[21120]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  1 09:17:01 debian CRON[31776]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  1 10:17:01 debian CRON[10046]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  1 11:17:01 debian CRON[20712]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  1 12:18:00 debian rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="538" x-info="http://www.rsyslog.com"] start
Aug  1 12:18:00 debian kernel: [    0.000000] Initializing cgroup subsys cpuset

Ich weiss bei beiden nicht so recht was die Einträge zu bedeuten haben, würde mich aber über Erläuterungen oder Vorschläge wo ich sonst nachsehen könnte freuen.
Gruß scale7

Edit: Aufstehen war wohl kurz vor 12:18.

[pferdefreund]

Wurde nach dem Neustart ein Filesystem-Check durchgeführt ? Eventuell war es ja einfach nur ein kurzer Stromausfall. Eventuell was in /var/log/kern.log zu finden ?

[rendegast]

libjavascriptcoregtk / webkit ist in debian ungewartet.
Da hier auch noch Fehler damit auftreten, sollte wohl auf Einsatz verzichtet werden.
Muß aber nichts mit Deinem Absturz zu tun haben.

(Strombedingte) Hardwarefehler, soweit sich nichts darüber findet, sind schwer zu diagnostizieren.
Netzteil / MB / Kabel / Festplatte / GraKa wären wohl nur über Austausch zu ermitteln.
Blöd, wenn der Fehler dann auch nur eher selten auftritt.
Vielleicht hast Du "Glück" und das Problem wird akut mit häufigen Abstürzen,
dann wäre ein Schadteil schneller identifiziert.
Ein diffuser Kernelfehler sollte nach Wechsel auf einen anderen Kernel oder sogar System
(kann ja auch im Zusammenspiel mit anderen Komponenten bedingt sein)
unterbleiben.

Rechnertausch?
Ist mit einem linux-System recht unspektakulär.



(EDIT Formatierung)

[geier22]

Mal ein paar Tips, wie man ein Problem einkreisen kann:

Wenn du den Fehler nochmal feststellst, merke dir zuallererst die Zeit, wenn du deinen Rechner wieder startest.

die Zeile

Code: Alles auswählen

Aug  2 14:17:05 debian rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="1501" x-info="http://www.rsyslog.com"] start

ist die erste Zeile die von rsyslog in den Syslog nach dem Start geschrieben wird.

Leider hast du zwar die Zeile auch in deinem Beitrag rein kopiert, aber nicht im Zusammenhang mit dem Absturz. da du ja offensichtlich am 1. August irgendwann vor 6:25 Uhr aufgestanden bist und deinen Rechner wieder zum Leben erweckt hast. Die Zeile stammt aber vom 12:18 Uhr.
Du könntest dich also nochmal gezielt auf die Suche machen.

Ereignisse, die deinen Rechner zum Schweigen brachten, müssen also direkt davor stehen (wenn sie überhaupt protokolliert wurden)
Diese Zeit dient dir dann auch als Anhaltspunkt für die Suche in anderen Log-Dateien, wie z.B. kern.log oder messages

Die Zeile, die von rendegast erwähnt wurde (libjavascriptcoregtk) stammt vom Jul 31 18:09:42 ---> warst du da noch am Rechner? Wenn ja ist sie für dein Problem nicht relevant.

[scale7]

Danke für eure Antworten.

pferdefreund: Ich war mir nicht sicher wie ich herausfinden kann ob ein Filesystem-Check durchgeführt wurde. Ich habe mich an dem ubuntuusers-wiki-Artikel https://wiki.ubuntuusers.de/Dateisystemcheck/ orientiert.

Code: Alles auswählen

dumpe2fs -h /dev/sda1 | grep -i "mount count"

liefert dann

Code: Alles auswählen

Mount count:              10
Maximum mount count:      -1

als Ausgabe (was bedeutet die -1?).

/var/log/kern.log scheint mir uninteressant:

Code: Alles auswählen

Jul 31 18:09:42 debian kernel: [475337.122863] uzbl-core[24229]: segfault at 0 ip 00007f01d6a88e20 sp 00007fffe4e0c2d8 error 4 in libjavascriptcoregtk-1.0.so.0.16.17[7f01d65c6000+6c8000]
Aug  1 12:18:00 debian kernel: [    0.000000] Initializing cgroup subsys cpuset

wobei der Eintrag von Jul 31 18:09:42 der letze vor dem Hochfahren meinerseits ist.

geier22: Tatsächlich fand das Aufstehen und Rechner-wieder-zum-Leben-erwecken um 12:18 statt (Student zu sein ist schön).
Mit der Zeile von 6:25 konnte ich nicht viel anfangen, da da aber "rsyslogd was HUPed" auftaucht, dachte ich zuerst dass um 6:25 der Rechner runtergefahren ist. Das passt aber nicht mit den Einträgen in /var/log/syslog zusammen, die für mich so aussehen als wäre das eher zwischen 11:17 und 12:18 passiert.

[geier22]

als Ausgabe (was bedeutet die -1?).

aus: https://wiki.ubuntuusers.de/Dateisystemcheck/

Seit Ubuntu 13.10 ist bei ext4-Partitionen standardmäßig "Maximum mount count: -1" gesetzt

=deaktiviert.
Tja offensichtlich haben Studenten die gleichen Schwierigkeiten wie ich, etwas ganz zu lesen
Wenn direkt vor 12:18 nichts verdächtiges zu finden ist, wird man wohl weiter im Dunkeln tappen.

Noch was:
Aktiviere die logging Funktion von systemd. Ist dem alten Zeugs von rsyslog schwer überlegen.
Für Interesse und zum Einlesen:
http://0pointer.de/blog/projects/journalctl.html

[MSfree]

Aktiviere die logging Funktion von systemd. Ist dem alten Zeugs von rsyslog schwer überlegen.

Nunja, man kann systemd auch weider normale syslog-Manieren beibringen, indem man in der Datei /etc/systemd/journald.conf die folgenden Einträge einstellt:

Code: Alles auswählen

Storage=none
ForwardToSyslog=yes
ForwardToWall=no

An die Überlegenheit vom Journal glaube ich nach wie vor nicht. Für mich sind normale ASCII-Logs, die man auch ohne spezielle Software von der Shell lesen kann (cat, less, grep...) immer noch im Vorteil im Vergleich zu binären Logdatenbanken.

[geier22]

Für mich sind normale ASCII-Logs, die man auch ohne spezielle Software von der Shell lesen kann (cat, less, grep...) immer noch im Vorteil im Vergleich zu binären Logdatenbanken.

Nun ist hier nicht der Ort darüber zu streiten aber eine Bemerkung sei mir erlaubt:
Die "spezielle" Software ist das Terminal und ein einziger Befehl (journalctl) der sich durch verschiedenen Optionen steuern läßt. Damit werden alle Varianten und Ausgabemöglichkeiten abgedeckt . Allein das empfinde ich als großen Vorteil, weil man sich nicht durch den Dschungel von allen möglichen Log - Dateien, Terminal- Befehlen und deren individuelle Optionen kämpfen muß. Auch das Problem der rotierenden Logs ist behoben [suche mal ältere Logs).
Ich habe so direkten Zugriff auf 36 Bootvorgänge und deren folgende Logs 3 Wochen zurück.
Dadurch ergibt sich eine sehr komfortable Bedienung und Suche durch den vollständigen Systemlog, ohne verschiedene Log-Dateien durchsuchen zu müssen.
Ich weiß nicht warum man ein wahnsinnig umständliches Verfahren bevorzugt, es sei denn aus guter alter Gewohnheit, oder weil man grundsätzlich gegen alles Neue ist. Da habe ich einen Vorteil, weil mein Intensiver Kontakt zu Linux und speziell Debian grad mal 2 Jahre zurück liegt.

[pferdefreund]

Und wie untersuche ich dann die Logfiles von einem Live-System aus, das noch keinen Systemd hat ? Soll ja auch mal vorkommen, dass der Rechner nur noch so zu starten ist. Und dann - ohne ASCII-Logs ? Ist zwar für den Heimanwender nicht wirklich so lebenswichtig aber es gibt ja auch Produktionssysteme.

[MSfree]

weil man sich nicht durch den Dschungel von allen möglichen Log - Dateien, Terminal- Befehlen und deren individuelle Optionen kämpfen muß.

Nunja, rsyslogd ist out-of-the-box scheußlich konfiguriert, es ist aber gar kein Problem. alles in ein Logfile fließen zu lassen.

Auch das Problem der rotierenden Logs ist behoben [suche mal ältere Logs).
Ich habe so direkten Zugriff auf 36 Bootvorgänge und deren folgende Logs 3 Wochen zurück.

Rotierte Logs sind kein Problem sondern die Lösung. Auch hier: out-of-the-box scheußliche Konfiguration. Wenn man will, kann man monatlich rotieren und die letzten 36 Logs aufheben, dann hast du Zugriff auf die letzten 3 Jahre und nicht nur 3 Wochen, was mir als Anwender viel zu wenig ist.

Ich weiß nicht warum man ein wahnsinnig umständliches Verfahren bevorzugt

Ich weiß es auch nicht: Eine Datenbank und binäre Logs sind einfach wahnsinnig komplizierter Overkill. Das ist aber nichts neues, denn rsyslogd kann auch in eine mysql Datenbank schreiben, wenn man will.

oder weil man grundsätzlich gegen alles Neue ist.

Ich bin bestimmt nicht grundsätzlich gegen alles Neue. Wenn das Neue aber nur um des Willens, neu sein zu müssen, eingebaut wird, ohne Zusatznutzen, dafür aber zusätzlichen Nachteilen, dann schalte ich auf stur.

[geier22]

Und wie untersuche ich dann die Logfiles von einem Live-System aus, das noch keinen Systemd hat ? Soll ja auch mal vorkommen, dass der Rechner nur noch so zu starten ist. Und dann - ohne ASCII-Logs ? Ist zwar für den Heimanwender nicht wirklich so lebenswichtig aber es gibt ja auch Produktionssysteme.

z.B. so (bin grad in Cinnamon unterwegs - Dual-Boot)

Code: Alles auswählen

journalctl --file /media/hans/XFCE_Root/var/log/journal/$(cat /etc/machine-id)/system.journal

Die letzten Zeilen aus Xfce:

Code: Alles auswählen

Aug 03 07:50:57 sparkyxfce systemd[1]: Stopped target Local File Systems (Pre).
Aug 03 07:50:57 sparkyxfce systemd[1]: Stopped Create Static Device Nodes in /dev.
Aug 03 07:50:57 sparkyxfce systemd[1]: Stopped Remount Root and Kernel File Systems.
Aug 03 07:50:57 sparkyxfce systemd[1]: Reached target Shutdown.
Aug 03 07:50:57 sparkyxfce systemd[1]: Reached target Final Step.
Aug 03 07:50:57 sparkyxfce systemd[1]: Starting Reboot...
Aug 03 07:50:57 sparkyxfce systemd[1]: Shutting down.
Aug 03 07:50:57 sparkyxfce systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Aug 03 07:50:57 sparkyxfce systemd-journald[1202]: Journal stopped

Nunja, rsyslogd ist out-of-the-box scheußlich konfiguriert, es ist aber gar kein Problem. alles in ein Logfile fließen zu lassen

Die Vorschläge,die du machst, um rsyslog zu optimieren sind für einen Profi sicherlich hilfreich und gut. Aber warum soll ich das machen, wenn mir ein Logsystem zur Verfügung gestellt wird, das (zumindest für mich) tadellos funktioniert ?

dann hast du Zugriff auf die letzten 3 Jahre und nicht nur 3 Wochen, was mir als Anwender viel zu wenig ist.

..du weist ja selber, wo man das in der /etc/systemd/journald.conf manipulieren kann

[MSfree]

Code: Alles auswählen

journalctl --file /media/hans/XFCE_Root/var/log/journal/$(cat /etc/machine-id)/system.journal

Sorry, beim Analysieren von Logs will ich mir eigentlich keinen Knoten in die Finger tippen.

Entsprechende Aliase, die man auf seinen System zur Arbeitserleichterung eingerichtet hat, existieren auf dem Notfallsystem, mit dem man die Möhre im Zweifelsfall zu retten versucht, genauso wenig wie z.B. journalctl oder diverse Tools, um die Datenbankdateien auszulesen.

Die Vorschläge,die du machst, um rsyslog zu optimieren sind für einen Profi sicherlich hilfreich und gut. Aber warum soll ich das machen, wenn mir ein Logsystem zur Verfügung gestellt wird, das (zumindest für mich) tadellos funktioniert ?

In alten Unixen und Linuxen war es üblich, alle Logs in ein /var/log/syslog fließen zu lassen. Das haben die Maintainer erst später in Mail-Logs, Print-Logs, Firewall-Logs etc. aufgeteilt und mehrere Dateien daraus gemacht. Ich fand das nie besonders praktisch, hat aber auch seinen Vorteile, weil man unterschiedlichen Admins einfach über entsprechende Rechtevergabe Zugriff nur auf bestimmte Logs geben konnte, der Vortteil ist nun dahin, weil wieder alles in ein Journal fließt (aber das mache ich bei mir mit rsyslogd ja auch).

[DeletedUserReAsG]

Sorry, beim Analysieren von Logs will ich mir eigentlich keinen Knoten in die Finger tippen.

Abgesehen davon, dass du den Pfad bei Textlogs genauso eintippen musst: das Geheimnis der Tab-Taste kennst du? Und dass man das journal auch ohne journalctl auslesen kann, weil die eigentlichen Einträge genau so darin landen, wie sie etwa rsyslogd entgegennehmen würde, ist auch bekannt? Ich meine, man selbst ist ja nicht dazu gezwungen, das journal zu mögen oder zu nutzen, wenn es einem nicht zusagt. Aber wegen „das haben wir immer so gemacht!!k“ jedem anderen erzählen zu wollen, dass das journal doof ist, und man gefälligst auf dessen Komfort verzichten soll und stattdessen Textlogs zu nutzen habe, erscheint mir irgendwie nicht ganz richtig.

Wie auch immer, ich würde es schon begrüßen, wenn wieder zum Thema des Threads zurückgefunden werden könnte. Ich befürchte, die drölfhundertste Diskussion zwischen systemd-Befürwortern und -gegnern hilft dem Threadstarter nicht so wirklich weiter.

[holgerw]

Hallo,

vor dem Auswerten von Log-Dateien - ob lieber mit systemd oder traditionell, dazu sage ich besser nichts - finde ich folgendes interessant:
1. Welches Debian? (stable/testing/unstable)
2. Wurde die Maschine zeitnah vor dem Absturz / oder dem Shutdown per upgrade / full-upgrade bzw, dist-upgrade auf einen aktuellen Stand gebracht?
3. Falls Du Stable nutzt: Verwendest Du auch den Kernel in stable main, oder nutzt Du andere Kernelquellen wie etwa Backports?

Wenn Du stable verwendest und nicht mit Kerneln aus anderen Quellen herumspielst, halte ich es für eher unwahrscheinlich, dass der ungewollte Shutdown (oder sogar der abrupte Stop der Maschine) etwas mit der Software zu tun hat.

Wird die Maschine vielleicht zu warm? Wann hast Du zum letzten Mal die Lüfter und das Rechnerinnere von Staub befreit? Erst wenn da Klarheit (in diesem Fall Staubfreiheit) herrscht, würde ich mit der Analyse über Logdateien beginnen.

Viele Grüße,
Holger

[MSfree]

das Geheimnis der Tab-Taste kennst du?

Ich bitte dich...

Und dass man das journal auch ohne journalctl auslesen kann, weil die eigentlichen Einträge genau so darin landen, wie sie etwa rsyslogd entgegennehmen würde, ist auch bekannt?

Dir ist der Unterschied zwischen reinen ASCII und Text plus binären Zusatzinformationen bekannt? Wenn nicht, dann öffne mal so eine Journaldatei, die dir per Mail zugeschickt wurde, im Outlook.

„das haben wir immer so gemacht!!k“

Das habe ich nicht geschrieben und ist auch nicht meine Ansicht. Leg mir bitte keine Wirte in den Mund.

jedem anderen erzählen zu wollen, dass das journal doof ist, und man gefälligst auf dessen Komfort verzichten soll und stattdessen Textlogs zu nutzen habe, erscheint mir irgendwie nicht ganz richtig.

Ständig das Gegenteil zu bahaupten ohne zu akzeptieren, daß es nunmal nicht nur Vorteile hat, in einem proprietären Binärformat zu speichern, ist genauso falsch.

Wie auch immer, ich würde es schon begrüßen, wenn wieder zum Thema des Threads zurückgefunden werden könnte.

Vergiß es.

Ich befürchte, die drölfhundertste Diskussion zwischen systemd-Befürwortern und -gegnern hilft dem Threadstarter nicht so wirklich weiter.

Es geht hier nicht um systemd sondern um die Art, wie Logs gespeichert sind. Logfiles in Datenbaken konnte rsyslogd schon unter SysV-Init vor 15 Jahren. Die Frage ist eher, warum hat das seitdem niemand genutzt und warum wird es einem jetzt aufgewungen?

[holgerw]

OffTopic: @MSfree,

ich kann hier nur empfehlen, aufgrund eigener Erfahrungen mit diesen systemd-Diskussionen und diesem Init-System (die u. a. dazu geführt haben, dass ich GNU/Linux auf Produktivmaschinen weitgehend nicht mehr einsetze), besser dem Hinweis von @niemand zu folgen, obgleich ich Deine Meinung hinsichtlich der Logs teile

Viele Grüße,
Holger