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

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 14:29:33

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

TomL

Re: [wieder vorhanden] Shutdown Problem

Beitrag von TomL » 27.03.2019 14:41:30

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 14:29:33
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.
Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 14:29:33
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

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 14:51:32

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. :lol:
Zuletzt geändert von Heliosstyx am 27.03.2019 14:52:45, insgesamt 1-mal geändert.

DeletedUserReAsG

Re: [wieder vorhanden] Shutdown Problem

Beitrag von DeletedUserReAsG » 27.03.2019 14:51:59

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 14:29:33
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

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 14:57:14

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

Re: [wieder vorhanden] Shutdown Problem

Beitrag von TomL » 27.03.2019 15:06:15

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 14:51:32
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.
Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 14:51:32
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.

Benutzeravatar
novalix
Beiträge: 1908
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: [wieder vorhanden] Shutdown Problem

Beitrag von novalix » 27.03.2019 17:53:23

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 14:57:14
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.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

TomL

Re: [wieder vorhanden] Shutdown Problem

Beitrag von TomL » 27.03.2019 18:40:49

novalix hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 17:53:23
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 :mrgreen:
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 :twisted:
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.... :twisted:

guennid

Re: [wieder vorhanden] Shutdown Problem

Beitrag von guennid » 27.03.2019 18:56:44

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

***duck und weg***

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 18:57:53

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.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 19:02:39

TomL: In welchem Verzeichnis finde ich denn mariadb.services zum editieren, wie Du vorgeschlagen hast? Die Persistenz der Protokolle ist von Haus aus (Buster) nicht aktiviert, warum eigentlich nicht?
Zuletzt geändert von Heliosstyx am 27.03.2019 19:07:33, insgesamt 1-mal geändert.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 19:05:44

Hier noch ein kleines Protokoll:

Code: Alles auswählen

sudo systemctl status mariadb.service
[sudo] Passwort für brumm: 
● mariadb.service - MariaDB 10.3.13 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-03-27 18:32:09 CET; 31min ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 893 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
  Process: 906 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 913 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl se
  Process: 1059 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 1068 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 Main PID: 1006 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 30 (limit: 4622)
   Memory: 86.6M
   CGroup: /system.slice/mariadb.service
           └─1006 /usr/sbin/mysqld

Mär 27 18:31:59 brumm-pc systemd[1]: Starting MariaDB 10.3.13 database server...
Mär 27 18:32:04 brumm-pc mysqld[1006]: 2019-03-27 18:32:04 0 [Note] /usr/sbin/mysqld (mysqld 10.3.13-MariaDB-1) starting as process 1006 ...
Mär 27 18:32:09 brumm-pc systemd[1]: Started MariaDB 10.3.13 database server.

TomL

Re: [wieder vorhanden] Shutdown Problem

Beitrag von TomL » 27.03.2019 19:43:24

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 18:57:53
Danke an alle meine Helfer. Hier sind die Protokolle für die oben angeführten Kommandos:
Sorry... bitte nimms mir nicht übel, aber so wird das nix. Es hilft nicht, wenn Du einfach unreflektiert und gedankenlos irgendwelche Befehle kopierst und die Antworten hier einstellst. Du müsstest Dich schon vorher mit dem Sinn eines Befehls und hinterher mit dem Inhalt der Antworten befassen. Und wenn ich hier z.B. mehrere Varianten von journalctl-Befehlen gepostet habe, kann man selber feststellen, welche für diesen besondern Fall die richtige ist. In meinem Folge-Post nach novalix habe ich sogar ganz konkret beschrieben, wie eine Vorgehensweise sein könnte.

Und es hilft auch nichts, wenn Du Dir nicht selber die Prokolle anschaust. Eigentlich ist es ganz offen erkennbar, dass deine Auszüge nur ein paar Zeilen vom Systemstart enthalten, genau das, was auf eine Bildschirmseite passt... aber es geht doch gar nicht um den Systemstart. Mein letztes Protokoll enthält über 1000 zeilen.... also muss ich mich auch ganz nach unten bewegen, wenn ich die Shutdown-Einträge sehen will. Und es bringt auch nix, hier 1000 Zeilen zu posten, wenns nur um den Shutdown geht. Und das hat jetzt alles noch nicht mal was mit "Linux-Anfänger" zu tun, sondern viel mehr mit Eigeninitiative......
Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 19:02:39
In welchem Verzeichnis finde ich denn mariadb.services zum editieren, wie Du vorgeschlagen hast?
Das findet man -wenns gar nicht anders geht- mit dem find-Befehl. Syntax-Beispiele findet man über die Suchmaschinen des Internets.
Die Persistenz der Protokolle ist von Haus aus (Buster) nicht aktiviert, warum eigentlich nicht?
Weil parallel noch rsyslog persistente (vorgekaute) Logs anlegt... die ich allerdings für die schlechtere Wahl halte. Das journal ist hingegen umfassend und supergut zu filtern und zu durchsuchen.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 20:13:53

Thomas: Sei mir nicht böse, was ich jetzt sage: Was heißt für Dich eigentlich Neuling bzw. Anfänger, das bedeutet normalerweise, dass man auf einem bestimmten Gebiet ganz am Anfang steht und das nötige Know-how erst aufbauen muss. Wie lange verwendest Du schon Linux, mindestens seit 2014, wenn ich mich nicht irre? Ich verwende Debian KDE jetzt gerade einmal gut einen Monat, vorher habe ich Fedora ein Jahr verwendet, dass sich von Debian schon teilweise stark unterscheidet. Bei Fedora braucht man sehr selten die Befehlszeile und somit Linux commands, wozu auch. Ich kopiere auch nicht wahllos Logs in dieses Forum, sondern sehe sie mir vorher an. Nur ich verstehe sie noch nicht vollständig, sonst bräuchte ich keine Hilfe und würde die Lösung im Forum einfach publizieren. Ich verwende die command line nur sehr selten und normalerweise habe ich auch keine Veranlassung, Fehler zu suchen, da sie bei mir selten auftreten. Wenn Du Linux commands oft verwendest, dann weißt Du sie aus dem "FF", ich aber nicht.

Ich versuche immer zuerst selbst eine Lösung zu finden und gehe erst dann fragen. Wenn ich oft am System manuell herum basteln würde,, dann würde ich die Verzeichnisstrukturen von Linux auswendig können, was ich nicht tue und wovon auch dringend abgeraten wird, denn dazu braucht es fundierte Systemkenntnisse. Ich bin Benutzer und kein Systemingenieur. In diesem Sinn bedarf es einer Richtigstellung, damit alle auf Augenhöhe miteinander kommunizieren können und keine Missverständnisse mehr vorliegen.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 27.03.2019 20:19:01

Thomas: Was heißt hier Eigeninitiative: was soll ich denn noch tun? Darf ich dann bitte um die Lösung bitten.

TomL

Re: [wieder vorhanden] Shutdown Problem

Beitrag von TomL » 27.03.2019 20:50:04

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 20:19:01
Thomas: Was heißt hier Eigeninitiative: was soll ich denn noch tun? Darf ich dann bitte um die Lösung bitten.
Eigeninitiative heisst, sich konkret mit dem Inhalt von Antworten zu befassen. Ich weise deshalb ganz entspannt zum zweiten Mal darauf hin:
TomL hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 19:43:24
In meinem Folge-Post nach novalix habe ich sogar ganz konkret beschrieben, wie eine Vorgehensweise sein könnte.

DeletedUserReAsG

Re: [wieder vorhanden] Shutdown Problem

Beitrag von DeletedUserReAsG » 27.03.2019 21:39:57

Hinwei am Rande: der Anfang der Ausgabe von journalctl -b -1 stellt gerade mal die ersten paar Millisekunden nach dem Einschalten dar. Hinweise zum Problem findest du aber allenfalls am Ende der Ausgabe (mit der Bild-runter-Taste kann man recht schnell scrollen; wenn der Pager less ist, gelangt man mit Shift+g direkt ans Ende).

Benutzeravatar
novalix
Beiträge: 1908
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: [wieder vorhanden] Shutdown Problem

Beitrag von novalix » 27.03.2019 21:43:15

Ok, lassen wir das mit dem journal vorläufig erst mal ruhen.

Ich habe auch, ehrlich gesagt, keine Ahnung, wie man systemd dazu bringt, seine Ausgaben so zu formatieren, dass ein Copy and Paste aus dem Pager gelingt, ohne die Hälfte abzuschneiden.

Einige interessante Informationen wären noch:
Läuft Dein Buster auf bare metal, also als natives Betriebssystem, oder in einer virtuellen Maschine?

Wie tickt die Uhr?
1. der Hardware
Mit Root-Rechten

Code: Alles auswählen

hwclock -r
2. des Betriebssystems

Code: Alles auswählen

date -R
Die Ausgaben der beiden Befehle sind zwar nicht exakt deckungsgleich, lassen sich aber ganz gut vergleichen.
Gibt es da offensichtliche Abweichungen?
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

DeletedUserReAsG

Re: [wieder vorhanden] Shutdown Problem

Beitrag von DeletedUserReAsG » 27.03.2019 22:14:55

novalix hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 21:43:15
Ich habe auch, ehrlich gesagt, keine Ahnung, wie man systemd dazu bringt, seine Ausgaben so zu formatieren, dass ein Copy and Paste aus dem Pager gelingt, ohne die Hälfte abzuschneiden.

Code: Alles auswählen

journalctl --help
[…]
   --no-pager              Do not pipe output into a pager
Leute, die gerne alles mit cat garnieren, könnten auch einfach journalctl -b -1 | cat schreiben.

TomL

Re: [wieder vorhanden] Shutdown Problem

Beitrag von TomL » 27.03.2019 22:26:12

novalix hat geschrieben: ↑ zum Beitrag ↑
27.03.2019 21:43:15
Ich habe auch, ehrlich gesagt, keine Ahnung, wie man systemd dazu bringt, seine Ausgaben so zu formatieren, dass ein Copy and Paste aus dem Pager gelingt, ohne die Hälfte abzuschneiden.
Speziell dieses Problem würde ich wie folgt lösen... das Wissen vorausgesetzt, dass ich gestern meinen Rechner kurz nach 23:00 ausgeschaltet habe:

Code: Alles auswählen

journalctl -b -1 --since "2019-03-26 23:00:00"  >/tmp/o
Danach kann ich 'o' mit einem beliebigen GUI-Editor/Viewer öffnen, markieren und und kopieren. Was mich aber interessiert, sind Deine Gedanken zur Uhr... wo ich jetzt annehme, dass da ein fundiertes Hintergrundwissen besteht, was mir fehlt und weswegen ich den Zusammenhang nicht verstehe.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 28.03.2019 11:05:49

Mein System ist ein dual-boot System mit Windows 10 und Debian Buster KDE in der aktuellen Version. Beide Betriebssystem laufen jeweils nativ, auf jeweils verschiedenen Festplatten. Die Uhrzeit-Differenzen zwischen beiden Betriebssystemen fallen insofern auf, als Windows um eine Stunde nachgeht, wenn man von Debian kommt, dieses Phänomen trat auch damals unter Linux Mint auf.

Hier die Zeitausgaben:

Code: Alles auswählen

sudo hwclock -r
[sudo] Passwort für brumm: 
2019-03-28 10:56:24.905556+01:00

Code: Alles auswählen

sudo date -R
Thu, 28 Mar 2019 10:56:55 +0100

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: [wieder vorhanden] Shutdown Problem

Beitrag von MSfree » 28.03.2019 11:19:42

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
28.03.2019 11:05:49
Die Uhrzeit-Differenzen zwischen beiden Betriebssystemen fallen insofern auf, als Windows um eine Stunde nachgeht, wenn man von Debian kommt, dieses Phänomen trat auch damals unter Linux Mint auf.
Debian und alle Unixe erwarten, daß die Hardwareuhr in UTC läuft. Windows hingegen erwartet, daß die Hardwareuhr in der lokalen Zeit läuft.

Man konnte aber Linux (also auch Debian) schon immer beibringen, daß die Hardwareuhr in der lokalen Zeit läuft. Bei einigen Linuxdistributionen wurde man sogar bei der Installation gefragt, ob die Hardwareuhr in der lokalen Zeit laufen soll. Bei Debian kann man das relativ leicht erreichen, in dem man die Zeile:

Code: Alles auswählen

HWCLOCKPARS=--localtime
in die Datei /etc/default/hwclock einträgt.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 28.03.2019 11:52:11

Danke für die Antwort. Was ist nun besser für Debian:

1. Auszug Debian Wiki:
In Debian the timezone for the hardware clock is configured in the file /etc/adjtime;

0.000000 14602224559 0.000000
1460224559
UTC

Edit /etc/adjtime, and change "UTC" to "LOCAL" if you want the hardware clock to be kept at local time instead of UTC.
2. oder Deine Möglichkeit.

3. Vielleicht ist die Uhrzeit wirklich das kritische Element für das mariadb shutdown-Problem: ich habe bei Ubunu folgendes gefunden: https://askubuntu.com/questions/892026/ ... ity-server

Mir ist völlig klar, dass Ubuntu nicht Debian ist, aber der Hinweis könnte die Lösung sein.

Ich habe die gleichen Systeme auf allen meinen Maschinen laufen, zeigen alle das gleiche Symptom.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: [wieder vorhanden] Shutdown Problem

Beitrag von MSfree » 28.03.2019 12:14:06

Heliosstyx hat geschrieben: ↑ zum Beitrag ↑
28.03.2019 11:52:11
Danke für die Antwort. Was ist nun besser für Debian:
Ein "besser" gibt es nicht. Ich würde auf einem System, auf dem nur Linux installiert ist, die Hardwareuhr auf UTC laufen lassen, zumal UTC auch keine Umschaltung zwischen Sommer- und Winterzeit kennt.

Bei einem Dualbootsystem mit WIndows ist es sinnvoll, die Hardwareuhr auf Lokalzeit laufen zu lassen, damit man nicht bei jedem abwechselnden Boot mit der Zeit zu kämpfen hat.

Am besten ist aber, einen NTP-Server zu verwenden, dann stellt sich die Systemzei über das Netz ein und die Probleme mit der Hardwareuhr sind uninteressant.
3. Vielleicht ist die Uhrzeit wirklich das kritische Element für das mariadb shutdown-Problem: ich habe bei Ubunu folgendes gefunden: https://askubuntu.com/questions/892026/ ... ity-server
Mir ist völlig klar, dass Ubuntu nicht Debian ist, aber der Hinweis könnte die Lösung sein.
Ubuntu ist auch Linux und es verwendet die gleichen Sourcecodes für ihre Software wie Debian, wenn auch in unterschiedlichen Revisionen. So weit sind die beiden also nicht auseinander, daß man nicht auch Ubuntu-Lösungsvorschläge nach Debian übertragen könnte. Einen Versuch ist es jedenfalls wert.

Heliosstyx

Re: [wieder vorhanden] Shutdown Problem

Beitrag von Heliosstyx » 28.03.2019 12:46:48

NTP Server läuft unter Buster KDE automatisch, allerdings korrigiert das nicht die eingebaute RTC clock, damit habe ich dann das Problem, dass es sein kann, dass die Startzeiten der Dienste in der Zukunft liegen (von Windows kommend) und der Zeitdienst dann zurückstellt....

Ich werde jetzt die RTC unter Debian auf local time stellen und dann beobachten, ob sich das mariadb shutdown Problem in Luft auflöst. Wenn ich mehr weiß, publiziere ich das Ergebnis. Es scheint aber offensichtlich so zu sein, dass keiner von euch Buster mit KDE verwendet und auch nicht in Verbindung mit Windows 10, daher haben wir lange "im Nebel gestochert" und keine Lösung gefunden. Du hast aber recht, dass viele Linux Distributionen (Fedora, Manjaro, Netrunner etc.) die Lokalzeit automatisch managen und so viele Probleme mit anderen Betriebssystemen erst gar nicht auftreten :mrgreen:

Antworten