[gelöst] Reboot/Shutdown Problem Debian Buster KDE

[willy4711]

einen riesen Hallas verursacht.

Bitte um Aufklärung was ein Hallas ist
fallst du das meinst:

Entfernt wurde folgendes:

Code: Alles auswählen

Start-Date: 2019-03-15  23:24:35
Commandline: apt purge mariadb*
Install: akonadi-backend-sqlite:amd64 (4:18.08.3-4, automatic) Purge: mariadb-common:amd64 (1:10.3.12-2), 
mariadb-server-core-10.3:amd64 (1:10.3.12-2), akonadi-backend-mysql:amd64 (4:18.08.3-4), mariadb-server-10.3:amd64 (1:10.3.12-2), 
default-mysql-server:amd64 (1.0.5), default-mysql-client-core:amd64 (1.0.5), mailutils:amd64 (1:3.5-2), 
mariadb-client-10.3:amd64 (1:10.3.12-2), mariadb-client-core-10.3:amd64 (1:10.3.12-2), libmailutils5:amd64 (1:3.5-2), 
libdbd-mysql-perl:amd64 (4.050-2), libmariadbclient18:amd64 (1:10.3.12-2), libmariadb3:amd64 (1:10.3.12-2), 
libqt4-sql-mysql:amd64 (4:4.8.7+dfsg-17), libqt5sql5-mysql:amd64 (5.11.3+dfsg-5) End-Date: 2019-03-15  23:24:54

Ob das bei deinem Problem Dauerhaft hilft ---> keine Ahnung

Finde ich nicht riesig

[novalix]

Damit stellst Du das DB-Backend von akonadi auf sqlite um. Das ist (Stand stretch) buggy as hell.
Du willst jemanden, von dem Du nicht weißt, was für Einsatzzwecke er mit seinem System beabsichtigt, nicht dazu raten ohne ihn vorher auf die Konsequenzen hinzuweisen, n' est-ce pas?

Und jetzt bitte, zurück zum Thema.

[TomL]

Der Befehl

Code: Alles auswählen

journalctl -u mariadb.service

listet alle Logeinträge, die mit mariadb im Zusammenhang stehen.
Es ist allerdings davon auszugehen, dass da nichts drin zu finden ist, was den letzten shutdown betrifft.

Ich glaube, dass auch danach nichts zu finden ist, weil nach meinem Verständnis beim Verlauf des Threads noch gar nicht erwiesen ist, dass mariadb tatsächlich als laufender Server installiert ist.... oder habe ich da irgendwas überlesen oder aufgrund besonderer KDE-Eigenarten (ich nutze es nicht) etwas übersehen?

Um bei dem Problem weiter zu kommen, muss erst mal dafür gesorgt werden, dass die Logs von systemd den reboot überleben.

Das sehe ich genauso, das ist eigentlich mit das wichtigste überhaupt.

[DeletedUserReAsG]

Ich glaube, dass auch danach nichts zu finden ist, weil nach meinem Verständnis beim Verlauf des Threads noch gar nicht erwiesen ist, dass mariadb tatsächlich als laufender Server installiert ist

Angesichts der Tatsache, dass der sich nicht beendende Stop-Job von mariadb das Ausgangsproblem ist, kann man aber davon ausgehen. Wenn’s nicht laufen würde, gäb’s das Problem nicht.

Ansonsten: ja, Logs wären dann hilfreich.

[eggy]

Nochmal ausführlich, falls mein vorheriger Kommentar missverständlich war:

Großer "Debian Vorteil": wenn Du nur Software hast, die übers Paketmanagement installiert wurde, dann wird Dich Dein Debian warnen, wenn Du versuchst etwas zu löschen, dass ein anderes Paket noch braucht. Ebenso wird es bei der Installation von Paket "a" ggfs dafür sorgen, dass auch "b" und "c" installiert werden, falls diese von "a" benötigt werden. Wobei Debian je nach Einstlellung hier zwischen "recommmend" und "suggested" unterscheidet.

Code: Alles auswählen

apt-config dump | grep "Install"

gibt nen paar Einträge, die beiden relevaten wären APT::Install-Recommends und APT::Install-Suggests. Sind die beide auf true gesetzt, wird viel mehr "nicht wirklich notwendiges" installiert, als bei jemanden der beide auf false hat. Das erstmal als Erklärung, warum bei Dir evtl andere Ergebnisse auftauchen, als bei anderen. Auch die Reihenfolge, welche Software man wann installiert, kann zu unterschiedlichen Abhängigkeitswegen geführt haben und dafür sorgen, dass Dein System etwas anders aussieht, als das von anderen.

apt-get hat den "-s" (simulate) Schalter, wie der Name schon sagt, passiert dabei Nichts, es gibt nur den Simulationslauf und das Paketmanagement sagt einem, was gemacht worden wäre. Also eh man jetzt lange rumexperimentiert und stundenlang überlegt, wo die Sachen herkommen, kann man auch einfach rausfinden, was passiert, wenn sie nicht mehr da wären:

Code: Alles auswählen

apt-get remove -s mariadb-common

[Heliosstyx]

Nun ein paar Antworten von mir:
1. Ich verwende den Standard-KDE Desktop, mit K-mail als E-Mail-Client. Keine speziellen Anpassungen und manuelle Eingriffe. eigentlich nur das, was Debian buster KDE Live ausliefert.

2. als Einsatzgebiet ist einfach das tägliche Arbeiten mit Debian auf einem HP Notebook vorgesehen, mit Schwerpunkt Audio-Produktion I(Ardour, Audacity, Gitarren Amplifier-Software, Notensatz-Software (musescore etc.).

3. Explizit installiert habe ich von allen mariadb-Komponenten gar nichts, wenn es wo mit installiert wurde, dann habe ich es geschehen lassen, "Nein" ohne Grund, dafür kenne ich die Tiefen von "Debian" zu wenig.

4. MySql läuft immer, wahrscheinlich wegen K-Mail (Status-Meldung gibt folgendes aus: "Your MariaDB connection id is 37
Server version: 10.3.13-MariaDB-1 Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others".
5. Bei mir sind sowohl mariadb-client.. und mariadb-server.. etc. Komponenten installiert. (Version 10.3.xxx)

Ich hoffe das hilft euch, besten Dank für eure großartige Hilfe.

Übrigens wie kann man in dieses Forum Texte (Logs etc.) kopieren, ohne gegen Regeln zu verstoßen. Wenn ihr noch Informationen braucht, ich stelle sie gern zur Verfügung.

[Heliosstyx]

Wenn ich das Kommando sudo apt-get remove -s mariadb-common ausführe, dann würde das System die HP-Druckertreiber, Mysql, Tellico, akonadi, HP-Scannertreiber Xsane und vieles mehr wegräumen, dem Gefühl nach den halben KDE Desktop entfernen und somit hätte ich nicht mehr viel, das noch funktioniert.

[Heliosstyx]

Das Kommando sudo journalctl -u mariadb.service ergibt folgenden Einträge

-- Logs begin at Sat 2019-03-16 17:54:44 CET, end at Sat 2019-03-16 18:05:34 CET. --
Mär 16 17:55:00 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 16 17:55:05 brumm-pc mysqld[1003]: 2019-03-16 17:55:05 0 [Note] /usr/sbin/mysqld (mysq
Mär 16 17:55:09 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.
Mär 16 17:55:09 brumm-pc /etc/mysql/debian-start[1059]: Upgrading MySQL tables if necessar

[novalix]

Das sind lediglich die Meldungen eines Starts.
Hast Du die oben angegebenen Schritte ausgeführt, um das Logging persistent zu machen?
Was ist die Ausgabe von

Code: Alles auswählen

ls -dl /var/log/journal

?

In der Icon-Leiste über dem Editor-Fenster findest Du einen Button, der mit einem Schrägstrich (slash) und zwei umgebenden spitzen Klammern gekenzeichnet ist "</>".
Wenn du den betätigst, erzeugst Du im Editor zwei Code-Tags. Dazwischen gehören solche Ausgaben, wie die von Deinem Log.

[rhHeini]

einen riesen Hallas verursacht.

Bitte um Aufklärung was ein Hallas ist

https://www.mundmische.de/bedeutung/14309-Hallas

[Heliosstyx]

Antwort an novalix: Das empfohlene Kommando liefert ein nicht vorhandenes Verzeichnis. Ich habe auch das persistent Machen des Protokolls nicht gefunden, bitte noch einmal angeben.

[JTH]

Ich habe auch das persistent Machen des Protokolls nicht gefunden, bitte noch einmal angeben.

Dazu reicht als root:

Code: Alles auswählen

# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal

Ab dem nächsten Reboot ist das Journal persistent.

[Heliosstyx]

Danke für die Antwort. Nach was soll ich im Protokoll suchen?. Wie kann ich die Persistenz nach der Lösung wieder entfernen, ich nehme an, dass die Persistenz der logs im Laufe der Zeit immer mehr Speicher verbraucht.

[MSfree]

ich nehme an, dass die Persistenz der logs im Laufe der Zeit immer mehr Speicher verbraucht.

Ja, natürlich wächst der Speicherbedarf. Bei mir stecken gerade 270 Tage an Logs in /var/log und deren Unterverzeichnissen. Der Speicherbedarf beträgt im Moment 94 Megabytes, also rund 270kByte pro Tag, bzw. 10 Jahre pro Gigabyte. Das ist vielleicht auf einem Raspi mit winziger 4GB µSD-Karte interessant, auf "normalen" Festplatte oder SSD ist das ziemlich vernachlässigbar.

[Heliosstyx]

Ich bedanke mich bei allen, die mir zu helfen versucht haben. Momentan tritt das Problem nicht mehr auf, was vielleicht daran liegt, dass "Buster" täglich Updates erhält und so das Problem derzeit vielleicht durch irgendein Update behoben wurde, dass ich allerdings nicht kenne. Ich werde den Thread jetzt temporär als gelöst kennzeichnen und ihn im Bedarfsfall wieder öffnen.

[Heliosstyx]

Leider ist das Shutdown-Problem wieder da:

der gewünschte Logfile output ergibt folgendes

Code: Alles auswählen

sudo ls -dl /var/log/journal
[sudo] Passwort für brumm: 
drwxr-sr-x+ 3 root systemd-journal 4096 Mär 27 14:13 /var/log/journal

Vielleicht könnt ihr etwas damit anfangen, ich weiß dafür zu wenig. Das Journal habe ich persistent gemacht, wie von euch angegeben. Was ich auch probiert habe ist: sudo systemctl stop mariadb.service bevor ich den Shutdown durchgeführt habe, dann fährt die Maschine einwandfrei herunter Was kann ich jetzt noch tun

[TomL]

Das Journal habe ich persistent gemacht, wie von euch angegeben.

Das hat nichts mit dem Problem zu tun, sondern nur mit der grundsätzlichen Protokollierung von System(- und Event)nachrichten.

sudo systemctl stop mariadb.service bevor ich den Shutdown durchgeführt habe, dann fährt die Maschine einwandfrei herunter Was kann ich jetzt noch tun

Ganz einfach, den Service-Stop automatisieren. Zeig mal den Inhalt der Service-Unit:

Code: Alles auswählen

systemctl cat mariadb.service

Möglicherweise ist es ausreichend, in der Unit-Section das folgende Statement zusätzlich einzutragen:

Code: Alles auswählen

Conflicts=shutdown.target 

Danach ein systemctl daemon-reload und das Problem ist möglicherweise gelöst.

[Heliosstyx]

Hier ist das Ergebnis:

Code: Alles auswählen

 systemctl cat mariadb.service
# /lib/systemd/system/mariadb.service
#
# /etc/systemd/system/mariadb.service
#
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Thanks to:
# Daniel Black
# Erkan Yanar
# David Strauss
# and probably others

[Unit]
Description=MariaDB 10.3.13 database server
Documentation=man:mysqld(8)
Documentation=https://mariadb.com/kb/en/library/systemd/
After=network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service
Alias=mysqld.service


[Service]

##############################################################################
## Core requirements
##

Bitte kannst Du genau angeben wie ich das einbauen soll und wo, ich bin ein Neuling auf diesem Gebiet. Wie kann ich die Persistenz der logfiles wieder zutücknehmen, was muss ich genau tun? Ich habe das getan, weil ihr die Information gebraucht habt. Danke.

[DeletedUserReAsG]

der gewünschte Logfile output ergibt folgendes
[…]

… hatte tatsächlich jemand gewünscht zu sehen, ob die Datei vorhanden ist, oder wurde eher nach deren Inhalt, mithin dem Log, gefragt? Letzteres kann man sich mittels journalctl anzeigen lassen.

[Heliosstyx]

Niemand: hier ist die Information, bitte schickt einen Neuling nicht im Kreis, das ist unfair. novalix schrieb: was ergibt ls -dl /var/log/journal

Code: Alles auswählen

sudo journalctl -u mariadb.service
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 14:54:59 CET. --
Mär 27 14:19:32 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 14:19:38 brumm-pc mysqld[1032]: 2019-03-27 14:19:38 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1032 ...
Mär 27 14:19:43 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: Looking for 'mysql' as: /usr/bin/mysql
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: This installation of MySQL is already upgraded to 10.3.13-MariaDB, use --force if you still 
-- Reboot --
Mär 27 14:34:09 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 14:34:15 brumm-pc mysqld[1041]: 2019-03-27 14:34:15 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1041 ...
Mär 27 14:34:21 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: Looking for 'mysql' as: /usr/bin/mysql
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: This installation of MySQL is already upgraded to 10.3.13-MariaDB, use --force if you still 
Mär 27 14:14:39 brumm-pc systemd[1]: Stopping MariaDB 10.3.13 database server...
-- Reboot --
Mär 27 14:36:48 brumm-pc systemd[1]: Stopping MariaDB 10.3.13 database server...
Mär 27 14:36:49 brumm-pc systemd[1]: mariadb.service: Succeeded.
Mär 27 14:36:49 brumm-pc systemd[1]: Stopped MariaDB 10.3.13 database server.
-- Reboot --
Mär 27 14:38:24 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 14:38:29 brumm-pc mysqld[1004]: 2019-03-27 14:38:29 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1004 ...
Mär 27 14:38:34 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.

[TomL]

Bitte kannst Du genau angeben wie ich das einbauen soll und wo, ich bin ein Neuling auf diesem Gebiet.

Wie ich sagte, auf dem Linux-System mit einem Linux-Editor (nano, vim, ne, mc-editor) einfach in die [Unit]-Section einfügen.

Wie kann ich die Persistenz der logfiles wieder zutücknehmen, was muss ich genau tun?

Das ist keine gute Idee und das solltest Du auch nicht zurücknehmen. Ich würde einfach das folgende "Paket" an die
/etc/systemd/journald.conf
ganz unten am Ende anfügen... dann bleibt das Journal eher klein, aber man kann trotzdem ein paar Tage zurückschauen.

Code: Alles auswählen

Storage=persistent
SystemMaxUse=20M
RuntimeMaxUse=20M
ForwardToSyslog=no
MaxLevelConsole=warning

Und jetzt, als nächstes, bevor Du irgendwas änderst, würde ich niemand's Rat befolgen und erst einmal einen Blick ins Journal werfen.

Code: Alles auswählen

journalctl -b                   # listet alle Nachrichten der aktuellen Sitzung
journalctl -b -1                # listet alle Nachrichten der vorherigen Sitzung
journalctl -b -2                # listet alle Nachrichten der vor-vorherigen Sitzung
journalctl -p err               # listet Fehlermeldungen
journalctl -u maria.service     # listet Meldungen einer bestimmten Unit

Wenn es die letzte Sitzung war, wo's gehangen hat, kannst Du Dir mit journactl -b -1 die Meldungen und die Zeitstempel ansehen... da kann man dann herausfinden, was genau wann und wie lange gestört hat.

[novalix]

Niemand: hier ist die Information, bitte schickt einen Neuling nicht im Kreis, das ist unfair. novalix schrieb: was ergibt ls -dl /var/log/journal

Code: Alles auswählen

sudo journalctl -u mariadb.service
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 14:54:59 CET. --
Mär 27 14:19:32 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 14:19:38 brumm-pc mysqld[1032]: 2019-03-27 14:19:38 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1032 ...
Mär 27 14:19:43 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: Looking for 'mysql' as: /usr/bin/mysql
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mär 27 14:19:45 brumm-pc /etc/mysql/debian-start[1097]: This installation of MySQL is already upgraded to 10.3.13-MariaDB, use --force if you still 
-- Reboot --
Mär 27 14:34:09 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 14:34:15 brumm-pc mysqld[1041]: 2019-03-27 14:34:15 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1041 ...
Mär 27 14:34:21 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: Looking for 'mysql' as: /usr/bin/mysql
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mär 27 14:34:24 brumm-pc /etc/mysql/debian-start[1123]: This installation of MySQL is already upgraded to 10.3.13-MariaDB, use --force if you still 
Mär 27 14:14:39 brumm-pc systemd[1]: Stopping MariaDB 10.3.13 database server...
-- Reboot --
Mär 27 14:36:48 brumm-pc systemd[1]: Stopping MariaDB 10.3.13 database server...
Mär 27 14:36:49 brumm-pc systemd[1]: mariadb.service: Succeeded.
Mär 27 14:36:49 brumm-pc systemd[1]: Stopped MariaDB 10.3.13 database server.
-- Reboot --
Mär 27 14:38:24 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 14:38:29 brumm-pc mysqld[1004]: 2019-03-27 14:38:29 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1004 ...
Mär 27 14:38:34 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.

Bei reboot 1 und 2 hat es geklemmt und bei reboot 3 nicht. Ist das richtig interpretiert?

Wenn das alles sein sollte, was man aus dem journal raus holen kann, dann hilft uns das leider nur sehr bedingt weiter.
Leider ist das tool "journalctl" (@TomL möge mir verzeihen) eine haarsträubende Katastrophe.
Da werden je nach gusto mal die Meldungen der Routine "/etc/mysql/debian-start" mit in die Sortierung gestellt oder auch nicht. Vorhanden sind sie in jedem Fall. Besonders hübsch ist der letzte timestamp vor reboot 2.

Probiere in jedem Fall noch die anderen vorgeschlagenen Filter für journalctl und stelle die Ergebnisse hier ein.
Vielleicht ergibt sich ja doch noch was erhellendes.

Danach können wir noch die Methode "Regentanz" in Angriff nehmen. Manchmal hilft das.

[TomL]

Wenn das alles sein sollte, was man aus dem journal raus holen kann, dann hilft uns das leider nur sehr bedingt weiter.

Deswegen habe ich mich auch gar nicht weiter an einer Interpretation dieser Auszüge versucht. Das ist völlig untauglich

Leider ist das tool "journalctl" (@TomL möge mir verzeihen) eine haarsträubende Katastrophe.

Ich hoffe, dass sich diese Aussage jetzt hier nur auf vorgenannten Auszug bezieht... und ne, da ist nix zu verzeihen... das ist eine Katastrophe *fg*. Allerdings ist dieser Auszug NICHT "das journal", sondern nur ein Filter auf Meldungen einer einzelnen konkreten Service-Unit. Ich halte für eine zeitnahe Abfrage des Status einer Unit allerdings

Code: Alles auswählen

systemctl status mariadb.service

für deutlich aussagefähiger.

Nur hilft beides gar nichts hinsichtlich des Status aus einer vorherigen Sitzung (vor reboot). Insofern hat dieser Auszug den gleichen Informationsgehalt wie der Wetterbericht von gestern, als ich wegen heftigem Regen den A***h ordentlich naß gekriegt habe. Und wenn dann noch im Wetterbericht drinsteht "Zeitweise Sonne" dann passt der Vergleich in etwa

Probiere in jedem Fall noch die anderen vorgeschlagenen Filter für journalctl und stelle die Ergebnisse hier ein.

Das ist die Lösung. Man muss warten, dass ein solcher Vorfall beim Shutdown passiert und das dann ggf. aussitzen. Im Regelfall sollte systemd den shutdown dann doch irgendwann erfolgreich zuende bringen können. Und dann untersucht man nach dem nächsten Start des Systems mit

Code: Alles auswählen

journalctl -b -1

das Journal auf Hinweise.... in dem man sich bis zu der Stelle bewegt, wo der letzte shutdown veranlasst wurde, um sich dann mit den Zeitstempeln zu befassen. Eigentlich sollte man da erkennen können, wo es hakt. Und wenn es wirklich diese eine service-unit ist, kanns sein, dass man das mit meinem conflict-Statement komfortabel und einfach lösen kann.

Danach können wir noch die Methode "Regentanz" in Angriff nehmen. Manchmal hilft das.

Ansonsten... Baströckchen und ein Tanz im Regen.... ist bestimmt hübsch anzuschauen....

[guennid]

Man könnte auch mal schauen, wie ein anderes init-System das Ungemach händelt.

***duck und weg***

[Heliosstyx]

Danke an alle meine Helfer. Hier sind die Protokolle für die oben angeführten Kommandos:

Code: Alles auswählen

sudo journalctl -b
[sudo] Passwort für brumm: 
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 18:38:18 CET. --
Mär 27 18:31:44 brumm-pc kernel: Linux version 4.19.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.
Mär 27 18:31:44 brumm-pc kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 root=UUID=304fbd35-711e-4616-b769-c6e3f8a40432 ro quiet splas
Mär 27 18:31:44 brumm-pc kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Mär 27 18:31:44 brumm-pc kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Mär 27 18:31:44 brumm-pc kernel: x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
Mär 27 18:31:44 brumm-pc kernel: BIOS-provided physical RAM map:
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bdea7fff] usable
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdea8000-0x00000000bdebefff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdebf000-0x00000000bdf80fff] usable
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdf81000-0x00000000bdfbefff] ACPI NVS
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdfbf000-0x00000000bdfdefff] usable
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdfdf000-0x00000000bdff6fff] ACPI data
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdff7000-0x00000000bdffffff] usable
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000be000000-0x00000000bfffffff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
Mär 27 18:31:44 brumm-pc kernel: BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
Mär 27 18:31:44 brumm-pc kernel: NX (Execute Disable) protection: active
Mär 27 18:31:44 brumm-pc kernel: SMBIOS 2.6 present.
Mär 27 18:31:44 brumm-pc kernel: DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/3624, BIOS F.46 08/25/2011
Mär 27 18:31:44 brumm-pc kernel: tsc: Fast TSC calibration using PIT
Mär 27 18:31:44 brumm-pc kernel: tsc: Detected 1995.083 MHz processor
Mär 27 18:31:44 brumm-pc kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Mär 27 18:31:44 brumm-pc kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

sudo journalctl -b -1
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 18:41:10 CET. --
Mär 27 14:38:09 brumm-pc kernel: Linux version 4.19.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.
Mär 27 14:38:09 brumm-pc kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 root=UUID=304fbd35-711e-4616-b769-c6e3f8a40432 ro quiet splas
Mär 27 14:38:09 brumm-pc kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Mär 27 14:38:09 brumm-pc kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Mär 27 14:38:09 brumm-pc kernel: x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
Mär 27 14:38:09 brumm-pc kernel: BIOS-provided physical RAM map:
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bdea7fff] usable
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdea8000-0x00000000bdebefff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdebf000-0x00000000bdf80fff] usable
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdf81000-0x00000000bdfbefff] ACPI NVS
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdfbf000-0x00000000bdfdefff] usable
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdfdf000-0x00000000bdff6fff] ACPI data
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdff7000-0x00000000bdffffff] usable
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000be000000-0x00000000bfffffff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
Mär 27 14:38:09 brumm-pc kernel: BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
Mär 27 14:38:09 brumm-pc kernel: NX (Execute Disable) protection: active
Mär 27 14:38:09 brumm-pc kernel: SMBIOS 2.6 present.
Mär 27 14:38:09 brumm-pc kernel: DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/3624, BIOS F.46 08/25/2011
Mär 27 14:38:09 brumm-pc kernel: tsc: Fast TSC calibration using PIT
Mär 27 14:38:09 brumm-pc kernel: tsc: Detected 1995.127 MHz processor
Mär 27 14:38:09 brumm-pc kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Mär 27 14:38:09 brumm-pc kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

sudo journalctl -b -2
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 18:43:55 CET. --
Mär 27 14:19:17 brumm-pc kernel: Linux version 4.19.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.
Mär 27 14:19:17 brumm-pc kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 root=UUID=304fbd35-711e-4616-b769-c6e3f8a40432 ro quiet splas
Mär 27 14:19:17 brumm-pc kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Mär 27 14:19:17 brumm-pc kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Mär 27 14:19:17 brumm-pc kernel: x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
Mär 27 14:19:17 brumm-pc kernel: BIOS-provided physical RAM map:
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bdea7fff] usable
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdea8000-0x00000000bdebefff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdebf000-0x00000000bdf80fff] usable
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdf81000-0x00000000bdfbefff] ACPI NVS
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdfbf000-0x00000000bdfdefff] usable
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdfdf000-0x00000000bdff6fff] ACPI data
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000bdff7000-0x00000000bdffffff] usable
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000be000000-0x00000000bfffffff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
Mär 27 14:19:17 brumm-pc kernel: BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
Mär 27 14:19:17 brumm-pc kernel: NX (Execute Disable) protection: active
Mär 27 14:19:17 brumm-pc kernel: SMBIOS 2.6 present.
Mär 27 14:19:17 brumm-pc kernel: DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/3624, BIOS F.46 08/25/2011
Mär 27 14:19:17 brumm-pc kernel: tsc: Fast TSC calibration using PIT
Mär 27 14:19:17 brumm-pc kernel: tsc: Detected 1995.053 MHz processor
Mär 27 14:19:17 brumm-pc kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Mär 27 14:19:17 brumm-pc kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

sudo journalctl -p err
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 18:45:12 CET. --
Mär 27 14:19:17 brumm-pc kernel: ACPI BIOS Error (bug): Failure creating [\_SB.PCI0.PEGP.VGA.LCD1.GBQC._T0], AE_ALREADY_EXISTS (20180810/dswload2-31
Mär 27 14:19:17 brumm-pc kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-221)
Mär 27 14:19:17 brumm-pc kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEGP.VGA.LCD1.GBQC, AE_ALREADY_EXISTS (20180810/psparse-516)
Mär 27 14:19:17 brumm-pc kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEGP.VGA.LCD1._BQC, AE_ALREADY_EXISTS (20180810/psparse-516)
Mär 27 14:19:31 brumm-pc dhclient[623]: Failed to get interface index: No such device
Mär 27 14:19:31 brumm-pc dhclient[623]: 
Mär 27 14:19:31 brumm-pc dhclient[623]: If you think you have received this message due to a bug rather
Mär 27 14:19:31 brumm-pc dhclient[623]: than a configuration issue please read the section on submitting
Mär 27 14:19:31 brumm-pc dhclient[623]: bugs on either our web page at www.isc.org or in the README file
Mär 27 14:19:31 brumm-pc dhclient[623]: before submitting a bug.  These pages explain the proper
Mär 27 14:19:31 brumm-pc dhclient[623]: process and the information we find helpful for debugging.
Mär 27 14:19:31 brumm-pc dhclient[623]: 
Mär 27 14:19:31 brumm-pc dhclient[623]: exiting.
Mär 27 14:19:32 brumm-pc systemd[1]: Failed to start Raise network interfaces.
Mär 27 14:20:43 brumm-pc /hp-systray[1885]: hp-systray[1885]: error: option -s not recognized
Mär 27 14:20:46 brumm-pc python3[1967]: backintime (brumm/1): ERROR: Back In Time is not configured!
-- Reboot --
Mär 27 14:33:56 brumm-pc kernel: ACPI BIOS Error (bug): Failure creating [\_SB.PCI0.PEGP.VGA.LCD1.GBQC._T0], AE_ALREADY_EXISTS (20180810/dswload2-31
Mär 27 14:33:56 brumm-pc kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-221)
Mär 27 14:33:56 brumm-pc kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEGP.VGA.LCD1.GBQC, AE_ALREADY_EXISTS (20180810/psparse-516)
Mär 27 14:33:56 brumm-pc kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEGP.VGA.LCD1._BQC, AE_ALREADY_EXISTS (20180810/psparse-516)
Mär 27 14:34:08 brumm-pc dhclient[680]: Failed to get interface index: No such device
Mär 27 14:34:08 brumm-pc dhclient[680]: 
Mär 27 14:34:08 brumm-pc dhclient[680]: If you think you have received this message due to a bug rather
Mär 27 14:34:08 brumm-pc dhclient[680]: than a configuration issue please read the section on submitting
Mär 27 14:34:08 brumm-pc dhclient[680]: bugs on either our web page at www.isc.org or in the README file
Mär 27 14:34:08 brumm-pc dhclient[680]: before submitting a bug.  These pages explain the proper
Mär 27 14:34:08 brumm-pc dhclient[680]: process and the information we find helpful for debugging.
Mär 27 14:34:08 brumm-pc dhclient[680]: 
Mär 27 14:34:08 brumm-pc dhclient[680]: exiting.
Mär 27 14:34:09 brumm-pc systemd[1]: Failed to start Raise network interfaces.
Mär 27 14:35:21 brumm-pc /hp-systray[1996]: hp-systray[1996]: error: option -s not recognized

sudo journalctl -u maria.service  
-- Logs begin at Wed 2019-03-27 14:14:20 CET, end at Wed 2019-03-27 18:47:23 CET. --
-- No entries --

Ich habe nichts auffälliges entdecken können, aber ich lerne gerade viel dazu. Vielleicht könnt ihr das besser beurteilen. Mir ist nur aufgefallen, dass das "Shutdown"-Problem nur dann auftritt, wenn ich vorher Updates für "Buster" erhalten habe, was momentan täglich der Fall ist. KMail verwendet MySQL (also MariaDB). Bin für weitere Hilfe sehr dankbar.