Debian 11.3 ("Bullseye") und KDE/Pim: vcf-Datei plötzlich 0 Byte groß

[prox]

Hi,

gestern stellte ich fest, dass die vcf-Datei, in der ich meine Kontakte für den Personal Information Manager (PIM) unter KDE lokal speichere in meinem Home-Verzeichnis, 0 Byte groß war.

Das bedeutete, dass ich in zu verschickenden E-Mails im PIM-Adressbuch keinerlei E-Mailadressen auswählen konnte. Ich musste die betreffende vcf-Datei aus meiner Datensicherung auf mein System zurückspielen um das Verhalten zu beheben. Meine gesicherte vcf-Datei ist ca. 143 Kb groß.

Das von mir festgestellte Verhalten kann wahrscheinlich nicht am Einspielen des Debian 11 Service Pack 3 gelegen haben, was auch gestern erfolgte (aber vor dem Auftreten des hier beschriebenen Verhaltens), denn den letzten vollen Backup meiner persönlichen Daten (inklusive der vcf-Datei) hatte ich nach dem Einspielen dieses Service Packs vorgenommen.

Hat jemand anders dieses Verhalten auch festgestellt?

Was könnte die Ursache für dieses Verhalten sein? Akonadi? Oder hat mir irgendjemand per remote meine Kontaktdaten geklaut, was ich nicht glaube?

[OrangeJuice]

Was könnte die Ursache für dieses Verhalten sein? Akonadi? Oder hat mir irgendjemand per remote meine Kontaktdaten geklaut, was ich nicht glaube?

Vielleicht ein defekt an der Hardware? Ich kenne das von Bilddateien, die plötzlich 0 Byte hatten. Ich meine, dass die SSD dafür verantwortlich war. Arbeitsspeicher wäre aber auch denkbar. Wie alt ist denn dein System oder der Arbeitsspeicher?

[prox]

Vielleicht ein defekt an der Hardware? Ich kenne das von Bilddateien, die plötzlich 0 Byte hatten. Ich meine, dass die SSD dafür verantwortlich war. Arbeitsspeicher wäre aber auch denkbar. Wie alt ist denn dein System oder der Arbeitsspeicher?

Das Gerät (Laptop) ist 8 Jahre alt, so lange ist auch die HD in dem Gerät. Der Arbeitsspeicher ist auch so alt. Hm, bisher sind mir an dem Gerät keine Hardwarefehler aufgefallen. Danke für Deinen Hinweis

[MSfree]

Vielleicht ein defekt an der Hardware?

Oder dist-upgrade bedingter Absturz.

Wenn man z.B. den Firefox offen hat während ein Firefox-Update eingespielt wird, verhält sich der Firefox zumindest eigenartig, einzelne Tabs stürzen ab... Nach eine Neustart des Firefox geht es dann wieder normal.

Analog dazu könnte das Update einen Prozeß in KDE angeschlagen haben, der dann abgestüzt ist. Sollte das beim Schreiben der vcf-Datei passiert sein, kann die Datei hinterher Unfug oder auch gar nichts enthalten. Sowas ist aber schwer reproduzierbar. Dateien zu aktualisieren, während ein Programm läuft, ist aber wie den Boden unter den Füssen wegziehen, das zieht immer komisches Verhalten nach sich.

[prox]

Wenn man z.B. den Firefox offen hat während ein Firefox-Update eingespielt wird, verhält sich der Firefox zumindest eigenartig, einzelne Tabs stürzen ab... Nach eine Neustart des Firefox geht es dann wieder normal.

Analog dazu könnte das Update einen Prozeß in KDE angeschlagen haben, der dann abgestüzt ist. Sollte das beim Schreiben der vcf-Datei passiert sein, kann die Datei hinterher Unfug oder auch gar nichts enthalten. Sowas ist aber schwer reproduzierbar. Dateien zu aktualisieren, während ein Programm läuft, ist aber wie den Boden unter den Füssen wegziehen, das zieht immer komisches Verhalten nach sich.

Danke für Deinen Hinweis, Msfree.

Soweit ich aus meiner Erinnerung heraus sagen kann, hat das Einspielen des SP 11.3 in mein System mittels apt-get upgrade das Verhalten nicht verursacht. Nach dem Einspielen des SP 11.3 habe ich keine weiteren Pakete aktualisiert, bis ich das Verhalten festgestellt hatte. Meine letzte volle Datensicherung hatte ich nämlich nach dem Einspielen des SP 11.3 erstellt, und in ihr ist meine vcf-Datei in einer Größe von ca 143 Kb enthalten. Das hier beschriebene Verhalten muss also nach der Erstellung meiner letzten Datensicherung verursacht worden sein.

[MSfree]

Das hier beschriebene Verhalten muss also nach der Erstellung meiner letzten Datensicherung verursacht worden sein.

Und wo ist der Widerspruch? Wenn das vermutete Programm erst nach deiner Sicherung abgestüzt sein sollte, ist die Datei auch erst nach der Sichergung kaputt gegangen.

[prox]

Das hier beschriebene Verhalten muss also nach der Erstellung meiner letzten Datensicherung verursacht worden sein.

Und wo ist der Widerspruch? Wenn das vermutete Programm erst nach deiner Sicherung abgestüzt sein sollte, ist die Datei auch erst nach der Sichergung kaputt gegangen.

Mein PIM ist gestern nicht abgestürzt, mir ist das jedenfalls nicht aufgefallen. Danke für den Hinweis

[prox]

gestern stellte ich fest, dass die vcf-Datei, in der ich meine Kontakte für den Personal Information Manager (PIM) unter KDE lokal speichere in meinem Home-Verzeichnis, 0 Byte groß war.

Das im Zitat beschriebene Verhalten ist übrigens ein zweites Mal vor ein paar Tagen wieder aufgetreten. Und wieder musste ich die vcf-Datei aus meinem Backup zurückspielen, um das Verhalten zu beheben.

Ich schaue gleich mal in die offizielle Debian-Bug-Datenbank rein, vielleicht gibt es ja dort einen Eintrag, der das hier beschriebene Verhalten dokumentiert.

Update: Nein, ich kann einen solchen Eintrag in der Debian-Bug-DB nicht finden. Vielleicht habe ich aber auch falsch gesucht.

[OrangeJuice]

Siehst du in den Logs segfaults etc.?

Code: Alles auswählen

journalctl | grep -i traps
journalctl | grep -i segfault

[prox]

Siehts du in den Logs segfaults etc.?

Code: Alles auswählen

journalctl | grep -i traps
journalctl | grep -i segfault

Danke für den Hinweis, OrangeJuice.

"journalctl | grep -i traps" liefert nur Hinweise auf den Web-Browser Opera.

"journalctl | grep -i segfault" ergibt für den Monat November 2022 (da ist das Verhalten zum letzten Mal aufgetreten):

Code: Alles auswählen

Nov 01 06:10:18 punk kernel: mysqld[1129]: segfault at 28 ip 00005607f605eed4 sp 00007f31900a7b70 error 4
Nov 01 13:01:10 punk kernel: mysqld[1136]: segfault at 28 ip 0000558aa1af5ed4 sp 00007ffb013efb70 error 4
Nov 01 16:33:55 punk kernel: mysqld[1138]: segfault at 28 ip 000055b230305ed4 sp 00007f03a47aeb70 error 4
Nov 02 13:25:47 punk kernel: mysqld[1137]: segfault at 28 ip 000055ac93f37ed4 sp 00007eff81f65b70 error 4 in mariadbd[55ac93bce000+8f0000]
Nov 02 15:46:01 punk kernel: mysqld[1145]: segfault at 28 ip 000056240e669ed4 sp 00007f797a127b70 error 4
Nov 03 21:48:35 punk kernel: mysqld[1136]: segfault at 28 ip 000055911de06ed4 sp 00007f87b2f1bb70 error 4
Nov 03 21:59:02 punk kernel: mysqld[1137]: segfault at 28 ip 0000560558cf9ed4 sp 00007f6361ff0b70 error 4 in mariadbd[560558990000+8f0000]
Nov 04 09:28:26 punk kernel: mysqld[1141]: segfault at 28 ip 0000564cade0ced4 sp 00007fa7dd96bb70 error 4
Nov 05 06:14:57 punk kernel: mysqld[1151]: segfault at 28 ip 000055e7f00e5ed4 sp 00007f83e4119b70 error 4
Nov 05 09:45:45 punk kernel: mysqld[1139]: segfault at 28 ip 00005572eee26ed4 sp 00007fbfa0d60b70 error 4 in mariadbd[5572eeabd000+8f0000]
Nov 06 06:59:36 punk kernel: mysqld[1165]: segfault at 28 ip 00005560fee39ed4 sp 00007f5c8860cb70 error 4 in mariadbd[5560fead0000+8f0000]
Nov 08 13:11:03 punk kernel: mysqld[1136]: segfault at 28 ip 00005649b3946ed4 sp 00007fa135222b70 error 4
Nov 10 22:02:14 punk kernel: mysqld[1134]: segfault at 28 ip 0000561a34c9bed4 sp 00007f8da5033b70 error 4 in mariadbd[561a34932000+8f0000]
Nov 11 09:18:14 punk kernel: mysqld[1136]: segfault at 28 ip 00005567a09d3ed4 sp 00007f9c040d0b70 error 4 in mariadbd[5567a066a000+8f0000]
Nov 12 09:56:34 punk kernel: mysqld[1139]: segfault at 28 ip 00005600c3869ed4 sp 00007f9be69fcb70 error 4
Nov 12 22:20:43 punk kernel: mysqld[1137]: segfault at 28 ip 00005653e83e9ed4 sp 00007fed6aed7b70 error 4 in mariadbd[5653e8080000+8f0000]
Nov 13 12:47:22 punk kernel: mysqld[1137]: segfault at 28 ip 000055bceb011ed4 sp 00007f6d50f2db70 error 4 in mariadbd[55bceaca8000+8f0000]
Nov 13 18:02:16 punk kernel: mysqld[1134]: segfault at 28 ip 000055f5b2ba8ed4 sp 00007efc400fab70 error 4
Nov 13 19:58:37 punk kernel: mysqld[1140]: segfault at 28 ip 000056178338fed4 sp 00007fbe104c0b70 error 4
Nov 14 21:00:29 punk kernel: mysqld[1134]: segfault at 28 ip 0000560677d34ed4 sp 00007f1de95a5b70 error 4
Nov 15 14:29:41 punk kernel: mysqld[1136]: segfault at 28 ip 00005584f0be0ed4 sp 00007faa7c0aab70 error 4
Nov 16 18:10:48 punk kernel: mysqld[1136]: segfault at 28 ip 000055e43fb77ed4 sp 00007f56340c9b70 error 4
Nov 17 10:00:41 punk kernel: mysqld[1140]: segfault at 28 ip 0000562318cfded4 sp 00007feb4c5c0b70 error 4 in mariadbd[562318994000+8f0000]
Nov 17 11:46:55 punk kernel: mysqld[1142]: segfault at 28 ip 0000557bba363ed4 sp 00007f4be8699b70 error 4 in mariadbd[557bb9ffa000+8f0000]
Nov 17 17:04:22 punk kernel: mysqld[1142]: segfault at 28 ip 0000560f91b2aed4 sp 00007f28c211ab70 error 4 in mariadbd[560f917c1000+8f0000]
Nov 18 21:13:42 punk kernel: mysqld[1140]: segfault at 28 ip 0000557420963ed4 sp 00007f6bb00beb70 error 4
Nov 19 22:02:08 punk kernel: mysqld[1137]: segfault at 28 ip 0000560d911aaed4 sp 00007f50441bfb70 error 4 in mariadbd[560d90e41000+8f0000]
Nov 20 06:57:18 punk kernel: mysqld[1168]: segfault at 28 ip 000055793f0e3ed4 sp 00007f04d40c1b70 error 4
Nov 20 20:00:38 punk kernel: mysqld[1140]: segfault at 28 ip 000055cbac371ed4 sp 00007f51ba816b70 error 4
Nov 21 07:08:51 punk kernel: mysqld[1155]: segfault at 28 ip 00005581f3f6eed4 sp 00007f93e40f3b70 error 4
Nov 21 15:23:55 punk kernel: MainThread[5948]: segfault at 0 ip 00007fac87c3fb79 sp 00007ffe8bb57148 error 6 in libxul.so[7fac87b85000+58e3000]
Nov 22 07:00:56 punk kernel: mysqld[1150]: segfault at 28 ip 00005631b730aed4 sp 00007fb2d43c0b70 error 4 in mariadbd[5631b6fa1000+8f0000]
Nov 22 22:09:36 punk kernel: mysqld[1139]: segfault at 28 ip 000055c70f9faed4 sp 00007f2764e39b70 error 4 in mariadbd[55c70f691000+8f0000]
Nov 23 09:07:19 punk kernel: mysqld[1135]: segfault at 28 ip 00005624449d6ed4 sp 00007effa5302b70 error 4
Nov 24 06:59:25 punk kernel: mysqld[1156]: segfault at 28 ip 000055eb9b0aaed4 sp 00007fb4380f7b70 error 4 in mariadbd[55eb9ad41000+8f0000]
Nov 24 12:42:16 punk kernel: mysqld[1137]: segfault at 28 ip 00005607a21eaed4 sp 00007f2b74eddb70 error 4 in mariadbd[5607a1e81000+8f0000]

Den genauen Tag, an dem das Verhalten zum letzten Mal aufgetreten ist, weiß ich nicht mehr, aber auf jeden Fall fand es in den letzten paar Tagen statt.

Mysqld hat doch auch was mit Akonadi zu tun, nicht wahr?

Die Meldung über den "MainThread[5948]" vom 21. November kann aber mit dem Verhalten nichts zu tun haben, weil aus meiner Erinnerung heraus das Verhalten spätestens am 20. November aufgetreten ist.

[OrangeJuice]

Wie weit reichen die Logs zurück und sind noch viele Traps/segfaults zu sehen?

Die segfaults und traps haben in meinem Fall mit dem Wechsel von der Crucial SSD hin zur NVME aufgehört. Nun hatte ich die SSD wieder in Betrieb und es gingen die Fehler nach einiger Zeit wieder los.

[prox]

Wie weit reichen die Logs zurück und sind noch viele Traps/segfaults zu sehen?

Die segfaults und traps haben in meinem Fall mit dem Wechsel von der Crucial SSD hin zur NVME aufgehört. Nun hatte ich die SSD wieder in Betrieb und es gingen die Fehler nach einiger Zeit wieder los.

Die Logs reichen bis März (2022?) zurück.

Wenn ich Deine beiden journalctl-Befehle eingebe, dauert es in beiden Fällen mehrere Minuten, bis die jeweilige Ausgabe dieser beiden Befehle in der Konsole erscheint. Es sind also sehr viele traps- und segfault-Einträge im Log von journalctl enthalten.

Meine HD (keine SSD) ist seit Kauf des betroffenen Geräts (2014) nicht ausgetauscht worden.

[OrangeJuice]

Stimmt, mit einer SSD oder NVME ist das schnell geladen.

Dann schau dir mal an wie die Smart Werte aussehen, vielleicht löst eine neue HHD,SSD... das Problem.

[MSfree]

Wenn ich Deine beiden journalctl-Befehle eingebe, dauert es in beiden Fällen mehrere Minuten

Entweder, du hast ein Problem mit deinem Datenträger oder die Logs sind dermassen groß, daß es Minuten dauert. Meine Journals reichen bis Oktober 2021 zurück und da dauert ein journalctl | grep boot vielleicht 5 Sekunden.

Ich würde mal die 8 Jahre alte Platte mit smartctl untersuchen. Es wäre auch sinnvoll, dein Journal nach IO-Errors zu durchsuchen.

[prox]

@OrangeJuice und @MSfree,

ich habe gerade Folgendes gemacht:

Code: Alles auswählen

root@punk:~# smartctl -q errorsonly -H /dev/sda
root@punk:~# smartctl -l error /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-19-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged

root@punk:~#

smartcl findet also keine Fehler.

Ich sollte mal die HD im betroffenen Gerät mit diesem einem Programm, das man aus dem Grub-Menü heraus starten kann (ist das immer noch so? Name des Programms mir gerade entfallen) und mit dem man die Festplatte testen kann, überprüfen. Mache ich bald.

Danke für Eure Hinweise.

[OrangeJuice]

Im Terminal kannst du es mit smartmontools auch gut auslesen, sonst geht es auch mit Gnome Disks, damit kann man auch einen längeren Selbsttest der Festplatte unterziehen.

Code: Alles auswählen

smartctl -x

[prox]

OrangeJuice, ich habe mal Folgendes gemacht:

Code: Alles auswählen

root@punk:~# smartctl -x /dev/sda | grep -i error
                                        was completed without error.
                                        without error or no self-test has ever 
Error logging capability:        (0x01) Error logging supported.
  1 Raw_Read_Error_Rate     POSR--   117   099   006    -    131470464
  7 Seek_Error_Rate         POSR--   083   060   030    -    212375594
184 End-to-End_Error        -O--CK   100   100   099    -    0
191 G-Sense_Error_Rate      -O--CK   100   100   000    -    368
199 UDMA_CRC_Error_Count    -OSRCK   200   200   000    -    0
                            ||||___ R error rate
0x01           SL  R/O      1  Summary SMART error log
0x02           SL  R/O      5  Comprehensive SMART error log
0x03       GPL     R/O      5  Ext. Comprehensive SMART error log
0x10       GPL     R/O      1  NCQ Command Error log
0x21       GPL     R/O      1  Write stream error log
0x22       GPL     R/O      1  Read stream error log
SMART Extended Comprehensive Error Log Version: 1 (5 sectors)
No Errors Logged
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short captive       Completed without error       00%        11         -
SCT Error Recovery Control command not supported
0x0001  2            0  Command failed due to ICRC error
root@punk:~#

Ob die letzte Zeile einen schwerwiegenden Fehler beschreibt? Keine Ahnung.

[prox]

Das Verhalten "vcf-Datei plötzlich 0 Byte groß" in Verbindung mit den Kontakten im KDE-Personal Information Manager bzw. in Kontact ist heute wieder aufgetreten: Die vcf-Datei mit all meinen gespeicherten Kontakten ist zum 3. Mal 0 Byte groß. Die Datei befindet sich übrigens im Hauptverzeichnis des Home-Verzeichnisses des betroffenen Users. Es gibt auf dem betroffenen Rechner neben dem root-Account nur einen einzigen Benutzer mit Standard-Benutzerrechten.

Irgendwo anders auf der HD scheinen keine derartigen, plötzlichen Datenverluste aufzutreten, denn der betroffene Rechner läuft seit Beginn des Auftretens des Verhaltens nicht auffällig fehlerhaft. Von den Datenverlusten ist also nur der KDE-Personal Information Manager bzw. Kontact betroffen.

[prox]

Update:

Beim Kopieren der vcf-Datei aus meinem Backup zurück in das Home-Verzeichnis des Standard-Benutzers (einfaches Kopieren in Dolphin) erschien vorhin die Meldung, dass die vcf-Datei heute (am 5.12.) um exakt 14 Uhr geändert worden ist.

Habe deswegen mal in die /var/log/messages geguckt, und um 14:00 Uhr am heutigen Tag fallen mir in dieser Datei folgende Zeilen auf:

Code: Alles auswählen

Dec  5 14:00:12 punk kernel: [ 6804.749489] audit: type=1400 audit(1670245212.359:24): apparmor="DENIED" operation="signal" profile="/usr/bin/akonadiserver" pid=1115 comm="akonadiserver" requested_mask="send" denied_mask="send" signal=term peer="unconfined"
Dec  5 14:00:13 punk org.kde.kdeconnect[4407]: kdeconnect.core: Could not query capabilities from notifications server
Dec  5 14:00:15 punk kernel: [ 6807.752293] audit: type=1400 audit(1670245215.364:25): apparmor="DENIED" operation="signal" profile="/usr/bin/akonadiserver" pid=1115 comm="akonadiserver" requested_mask="send" denied_mask="send" signal=kill peer="unconfined"
Dec  5 14:00:20 punk org.kde.kdeconnect[4407]: ICE default IO error handler doing an exit(), pid = 4407, errno = 11

Ich weiß jetzt nicht, ob vielleicht doch der Akonadi-Server hinter dem Verhalten steckt, das in diesem Thread hier beschrieben ist.

[prox]

Update:

Habe mal folgenden Befehl ausgeführt als Benutzer root:

Code: Alles auswählen

journalctl | grep 'Nov 05 14:00'

Da kam Folgendes bei raus:

Code: Alles auswählen

Nov 05 14:00:01 punk CRON[3559]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Nov 05 14:00:01 punk CRON[3561]: (root) CMD (/sbin/hwclock --systohc)
Nov 05 14:00:01 punk CRON[3560]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Nov 05 14:00:01 punk CRON[3562]: (root) CMD (/usr/sbin/ntpdate -u ntp1.m-online.net)
Nov 05 14:00:02 punk CRON[3559]: pam_unix(cron:session): session closed for user root
Nov 05 14:00:08 punk CRON[3560]: (CRON) info (No MTA installed, discarding output)
Nov 05 14:00:08 punk CRON[3560]: pam_unix(cron:session): session closed for user root
Nov 05 14:00:24 punk kernel: perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79750

Die hier genannten Programme hwclock und ntpdate sind auf dem betroffenen Rechner in einem cronjob definiert, "crontab -e" als Benutzer root ergibt:

Code: Alles auswählen

4-20 * * * /usr/sbin/ntpdate -u ntp1.m-online.net
4-20 * * * /sbin/hwclock --systohc

Das ist auch der einzige cronjob für Benutzer root. Für den Standard-Benutzer habe ich keinen cronjob definiert.

Muss ich also davon ausgehen, dass der genannte cronjob das in diesem Thread beschriebene Verhalten verursacht, aber nur sporadisch? Schließlich wird der cronjob jeden Tag zwischen 4 und 20 Uhr einmal stündlich ausgeführt, aber so oft tritt das Verhalten, das hier in diesem Thread beschrieben ist, ja nicht auf. Bei Weitem nicht. Das Verhalten ist innerhalb der letzten Monate nur 3 Mal aufgetreten.

Oder hat der Kernel das in diesem Thread beschriebene Verhalten verursacht?

[MSfree]

Habe mal folgenden Befehl ausgeführt als Benutzer root:

Code: Alles auswählen

journalctl | grep 'Nov 05 14:00'

Und was hast du dir davon versprochen?

In deinem Journalauszug steht, daß cron seine root-Jobs erfolgreich ausgeführt wurde.

Mir ist auch völlig unklar, warum die deine Uhrzeit stündlich aktualisierst. Einerseits ist die Systemuhr auf dem Mainboard in der Regel nicht schlechter als ein paar Sekunden pro Tag. Andererseits macht systemd das ohnehin alle paar Sekunden, ein weiterer cron-Job ist also völlig überflüssig (schadet aber auch nicht).

Was aber soll das mit dem Pim-Problem des normalen Benutzers zu tun haben? Schaust du bei deinem Auto, wenn eine Scheinwerferbirne ausgefallen ist, auch erstmal, wieviel Sprit noch im Tank ist?

[prox]

Habe mal folgenden Befehl ausgeführt als Benutzer root:

Code: Alles auswählen

journalctl | grep 'Nov 05 14:00'

Und was hast du dir davon versprochen?

Möglicherweise die Ursache für das hier beschriebene Verhalten ausfindig machen. Dafür könnte doch journalctl taugen, oder etwa nicht?

In deinem Journalauszug steht, daß cron seine root-Jobs erfolgreich ausgeführt wurde.

Jo.

Mir ist auch völlig unklar, warum die deine Uhrzeit stündlich aktualisierst. Einerseits ist die Systemuhr auf dem Mainboard in der Regel nicht schlechter als ein paar Sekunden pro Tag. Andererseits macht systemd das ohnehin alle paar Sekunden, ein weiterer cron-Job ist also völlig überflüssig (schadet aber auch nicht).

Ok, danke für die Info. Auf meinem alten Rechner, sicherlich 15 Jahre alt, wurde die Zeit nicht genau angezeigt, sie hinkte hinter der echten Zeit hinterher. Deswegen meine beiden Cronjobs. Aber gut, dann kommentiere ich die mal aus. Danke.

Was aber soll das mit dem Pim-Problem des normalen Benutzers zu tun haben? Schaust du bei deinem Auto, wenn eine Scheinwerferbirne ausgefallen ist, auch erstmal, wieviel Sprit noch im Tank ist?

Haha Ich wollte einfach mal dokumentieren, was journalctl so ausspuckt über den Zeitpunkt, an dem das hier beschriebene Verhalten zum letzten Mal passiert ist. Um vielleicht einen weiteren Hinweis von anderen Usern zu bekommen.

Aber ich habe vorhin einen Fehler gemacht, ich hatte als Benutzer root mittels grep nach "Nov 05 14:00" in der Ausgabe von journalctl gesucht, wir haben aber mittlerweile Dezember. Der Befehl muss also richtigerweise lauten:

Code: Alles auswählen

journalctl | grep 'Dez 05 14:00'

Der Output ist ein jetzt anderer und sehr viel länger. Er scheint u. a. einen Rechner-Shutdown zu dokumentieren. Ich werde gleich mal den Output nach NoPaste hochladen. Eine vcf-Datei ist darin aber nicht genannt.

Hier der Link zum NoPaste-Log:

pastebin/?mode=view&s=41832

[MSfree]

Hier der Link zum NoPaste-Log:
pastebin/?mode=view&s=41832

Ich sehe da ein paar Zeilen, bei denen AppArmor dem Akonadi-Server irgendwas verweigert. Ob das mit deinem Problem zu tun hat, weiß ich nicht, es ist aber naheliegend, weil sich Akonadi um PIM-Funktionen kümmert.

Ich habe mich von KDE verabschiedet, als mit KDE4 Akonadi eingeführt wurde. Das hat bei mir damals nur Probleme gemacht. Leider funktioniert KDE seither nicht mehr ohne Akonadi.

[prox]

Ich sehe da ein paar Zeilen, bei denen AppArmor dem Akonadi-Server irgendwas verweigert. Ob das mit deinem Problem zu tun hat, weiß ich nicht, es ist aber naheliegend, weil sich Akonadi um PIM-Funktionen kümmert.

Danke fürs Reinschauen ins Log und für Deine Interpretation, MSfree. Ich glaube, mir sind heute Morgen diese Zeilen im Log auch aufgefallen.

Als ich die vcf-Datei aus der Datensicherung auf dem USB-Stick in Dolphin zurückkopierte auf den betroffenen Rechner um die leere vcf-Datei auf dem Rechner mit der Datei aus der Datensicherung zu ersetzen, erschien ja in Dolphin in einem externen Fenster die Meldung, dass die vcf-Datei auf dem Rechner am 5.12.2022 um 14 Uhr zuletzt geändert worden sei. Deswegen ja meine Suche per journalctl. Leider habe ich mir von dieser Meldung in Dolphin keinen Screenshot angefertigt.

Alternativ (Notiz für mich) kann ich den Zeitstempel der letzten Änderung an einer Datei mit dem folgenden Befehl herausfinden:

Code: Alles auswählen

ls -clt <Datei>

Ich habe mich von KDE verabschiedet, als mit KDE4 Akonadi eingeführt wurde. Das hat bei mir damals nur Probleme gemacht. Leider funktioniert KDE seither nicht mehr ohne Akonadi.

Ja, die Nicht-Akonadi-Zeiten habe ich unter KDE auch mitbekommen, fand ich damals auch besser als dann irgendwann mit Akonadi. Aber ich mag den PIM bzw. Kontakt bzw. KDE generell, also bleibe ich dabei.

[prox]

Das Verhalten ist wieder aufgetreten. Wann?

xxx@punk:~$ ls -clt kontakte_KONTACT.vcf
-rw-r--r-- 1 xxx xxx 0 6. Apr 10:07 kontakte_KONTACT.vcf
xxx@punk:~$

Der Inhalt der *.vcf-Datei soll also heute um 10:07 Uhr gelöscht worden sein. Merkwürdig. Mir fiel das Verhalten heute morgen bereits um ca. 06:15 Uhr auf, als ich eine Mail aus PIM/Kmail heraus abschicken wollte und dabei den Empfänger aus dem Adressbuch heraussuchen wollte, was nicht ging, weil das Adressbuch leer war.

Erklärung hierfür: Offenbar wurde die *.vcf-Datei heute um 10:07 Uhr ein zweites Mal vom System geändert.

So, ich schaue mir das mal weiter an. Fortsetzung folgt gleich.