staging.inyokaproject.org

Hallo,

ich benutze seit vielen Jahren Kontact und war bisher zufrieden.

Seit etwa 14 Tagen stürzt KAddressBook ab: Wenn ich in Kontact auf "Kontakte" clicke, stürzt das Programm ab.

Meine Kontakte sind noch da, liegen alle in ~/.local/.share/.contacts im Format .vcf .

Ich möchte auf die Kontakte zugreifen, weiß aber nicht wie. Was im Wiki https://wiki.ubuntuusers.de/Adressbuch/ steht klingt nicht so vertrauenerweckend, was Alternativen von KAddressBook angeht.

Deshalb meine Frage(n):

Kennt jemand das Problem?

Welches Adressbuch sollte ich verwenden?

Macht es Sinn KAddressBook neu zu installieren?

Danke für Hinweise und Hilfe,

Malefiz

Hallo!

Hast du irgendwelche PPA im System, die Plasma-Pakete (oder Qt) ändern? Wenn ja, bitte angeben!

KAddressBook im Terminal aufrufen:

akonadictl fsck  # akonadi prüfen/reparieren
akonadictl status # plugins,etc. anzeigen
kaddressbook

Dann schau mal, was da crasht. Bitte Ausgaben im Codeblock oder bei längeren Ausgaben den PasteService nutzen.

Hallo ChickenLipsRfun2eat,

danke!

ChickenLipsRfun2eat schrieb:

Hallo!

Hast du irgendwelche PPA im System, die Plasma-Pakete (oder Qt) ändern? Wenn ja, bitte angeben!

Nicht, das ich wüsste ... (und ich weiß auch nicht, wie ich das rauskriegen sollte.)

KAddressBook im Terminal aufrufen:

akonadictl fsck # akonadi prüfen/reparieren

Das sieht wie folgt aus:

Looking for resources in the DB not matching a configured resource...
Looking for collections not belonging to a valid resource...
Checking collection tree consistency...
Looking for items not belonging to a valid collection...
Looking for item parts not belonging to a valid item...
Looking for item flags not belonging to a valid item...
Looking for overlapping external parts...
Verifying external parts...
Found 3775 external files.
Found 3775 external parts.
Found no unreferenced external files.
Checking size threshold changes...
Found 0 parts to be moved to external files
Found 0 parts to be moved to database
Looking for dirty objects...
Collection "Search" (id: 1) has no RID.
Collection "OpenInvitations" (id: 16) has no RID.
Collection "DeclinedInvitations" (id: 17) has no RID.
Collection "Letzte Suche" (id: 229) has no RID.
Found 4 collections without RID.
Item "23636" in collection "13" has no RID.
Item "23637" in collection "13" has no RID.
Item "23638" in collection "13" has no RID.
Item "23639" in collection "13" has no RID.
Item "23641" in collection "13" has no RID.
Item "24705" in collection "13" has no RID.
Item "25051" in collection "13" has no RID.
Item "25057" in collection "13" has no RID.
Item "25058" in collection "13" has no RID.
Item "25107" in collection "13" has no RID.
Item "27466" in collection "13" has no RID.
Item "29443" in collection "13" has no RID.
Item "29818" in collection "13" has no RID.
Item "29823" in collection "13" has no RID.
Item "30161" in collection "13" has no RID.
Item "31095" in collection "222" has no RID.
Item "31097" in collection "222" has no RID.
Item "33317" in collection "142" has no RID.
Item "33347" in collection "13" has no RID.
Item "33348" in collection "13" has no RID.
Item "33349" in collection "13" has no RID.
Item "33350" in collection "13" has no RID.
Item "33351" in collection "13" has no RID.
Item "35402" in collection "13" has no RID.
Found 24 items without RID.
Item "33340" has RID and is dirty.
Found 1 dirty items.
Looking for rid-duplicates not matching the content mime-type of the parent collection

>> Jetzt kommt für jeden Mail-Ordner:
Checking "Mail-Ordner"
>> Ende der Mail-Ordner

Migrating parts to new cache hierarchy...
Checking search index consistency...
Skipping virtual Collection 1
Checking Collection 4 search index...
Checking Collection 5 search index...
Checking Collection 12 search index...
Checking Collection 13 search index...
Checking Collection 15 search index...
Skipping virtual Collection 16
Skipping virtual Collection 17
Checking Collection 18 search index...
Checking Collection 19 search index...
Checking Collection 20 search index...
Checking Collection 21 search index...
Checking Collection 22 search index...
Checking Collection 23 search index...
Checking Collection 24 search index...
Checking Collection 25 search index...
Checking Collection 26 search index...
Checking Collection 27 search index...
Checking Collection 28 search index...
Checking Collection 29 search index...
Checking Collection 30 search index...
Checking Collection 31 search index...
Checking Collection 32 search index...
Checking Collection 119 search index...
Checking Collection 120 search index...
Checking Collection 121 search index...
Checking Collection 122 search index...
Checking Collection 123 search index...
Checking Collection 124 search index...
Checking Collection 125 search index...
Checking Collection 126 search index...
Checking Collection 127 search index...
Checking Collection 128 search index...
Checking Collection 129 search index...
Checking Collection 130 search index...
Checking Collection 132 search index...
Checking Collection 133 search index...
Checking Collection 134 search index...
Checking Collection 135 search index...
Checking Collection 136 search index...
Checking Collection 137 search index...
Checking Collection 138 search index...
Checking Collection 139 search index...
Checking Collection 140 search index...
Checking Collection 141 search index...
Checking Collection 142 search index...
Checking Collection 143 search index...
Checking Collection 144 search index...
Checking Collection 145 search index...
Checking Collection 146 search index...
Checking Collection 148 search index...
Checking Collection 151 search index...
Checking Collection 152 search index...
Checking Collection 153 search index...
Checking Collection 154 search index...
Checking Collection 155 search index...
Checking Collection 156 search index...
Checking Collection 157 search index...
Checking Collection 158 search index...
Checking Collection 159 search index...
Checking Collection 160 search index...
Checking Collection 161 search index...
Checking Collection 162 search index...
Checking Collection 163 search index...
Checking Collection 164 search index...
Checking Collection 165 search index...
Checking Collection 166 search index...
Checking Collection 167 search index...
Checking Collection 168 search index...
Checking Collection 169 search index...
Checking Collection 170 search index...
Checking Collection 171 search index...
Checking Collection 172 search index...
Checking Collection 173 search index...
Checking Collection 174 search index...
Checking Collection 175 search index...
Checking Collection 176 search index...
Checking Collection 177 search index...
Checking Collection 178 search index...
Checking Collection 179 search index...
Checking Collection 180 search index...
Checking Collection 181 search index...
Checking Collection 182 search index...
Checking Collection 183 search index...
Checking Collection 184 search index...
Checking Collection 185 search index...
Checking Collection 186 search index...
Checking Collection 187 search index...
Checking Collection 188 search index...
Checking Collection 189 search index...
Checking Collection 190 search index...
Checking Collection 191 search index...
Checking Collection 192 search index...
Checking Collection 193 search index...
Checking Collection 194 search index...
Checking Collection 196 search index...
Checking Collection 197 search index...
Checking Collection 198 search index...
Checking Collection 199 search index...
Checking Collection 200 search index...
Checking Collection 201 search index...
Checking Collection 202 search index...
Checking Collection 203 search index...
Checking Collection 204 search index...
Checking Collection 205 search index...
Checking Collection 206 search index...
Checking Collection 207 search index...
Checking Collection 210 search index...
Checking Collection 211 search index...
Checking Collection 212 search index...
Checking Collection 214 search index...
Checking Collection 216 search index...
Checking Collection 218 search index...
Checking Collection 221 search index...
Checking Collection 222 search index...
Checking Collection 223 search index...
Checking Collection 225 search index...
Checking Collection 228 search index...
Skipping virtual Collection 229
Checking Collection 231 search index...
Checking Collection 232 search index...
Flushing collection statistics memory cache...
Making sure virtual search resource and collections exist
Consistency check done.

akonadictl status # plugins,etc. anzeigen

Akonadi Control: running
Akonadi Server: running
Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin)
Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_followupreminder_agent, akonadi_google_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mailmerge_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource

kaddressbook

Jetzt "läuft" kaddressbook, ich kann zumindest einzelne Kontakte anclicken. ABER: Sobald ich mit der Maus oder den Pfeiltasten in den Kontakten scrolle stürzt kaddressbook wieder ab. Das ist die Fehlermeldung :

terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: Wrong payload type (requested: sp(0)<KContacts::Addressee>; present: sp(2)<KCalendarCore::Incidence*>)
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kaddressbook path = /usr/bin pid = 5415
KCrash: Arguments: /usr/bin/kaddressbook 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi

[1]+  Angehalten              kaddressbook
xxx@xxx-desktop:~$ kaddressbook
terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: Wrong payload type (requested: sp(0)<KContacts::Addressee>; present: sp(2)<KCalendarCore::Incidence*>)
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kaddressbook path = /usr/bin pid = 5452
KCrash: Arguments: /usr/bin/kaddressbook 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
QSocketNotifier: Invalid socket 18 and type 'Read', disabling...

[2]+  Angehalten              kaddressbook
xxx@xxx-desktop:~$ Unable to find file for pid 5415 expected at "kcrash-metadata/5415.ini"
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
QSocketNotifier: Invalid socket 17 and type 'Read', disabling...
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
QSocketNotifier: Invalid socket 24 and type 'Read', disabling...
QSocketNotifier: Invalid socket 18 and type 'Read', disabling...
QSocketNotifier: Invalid socket 19 and type 'Read', disabling...
QSocketNotifier: Invalid socket 20 and type 'Read', disabling...
QSocketNotifier: Invalid socket 25 and type 'Read', disabling...
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
Unable to find file for pid 5452 expected at "kcrash-metadata/5452.ini"
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 24 and type 'Read', disabling...
QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
QSocketNotifier: Invalid socket 17 and type 'Read', disabling...
QSocketNotifier: Invalid socket 19 and type 'Read', disabling...
QSocketNotifier: Invalid socket 20 and type 'Read', disabling...
QSocketNotifier: Invalid socket 25 and type 'Read', disabling...
Unable to start Dr. Konqi
Re-raising signal for core dump handling.

Viele Grüße Malefiz

Malefiz schrieb:

Nicht, das ich wüsste ... (und ich weiß auch nicht, wie ich das rauskriegen sollte.)

Dann fangen wir damit an:

1
2
3
4

sudo apt update && sudo apt full-upgrade && sudo apt autoremove && sudo snap refresh # volle Systemaktualisierung
snap list  # alle snaps auflisten
dpkg -l | grep kaddr  # debian packages mit Stichwort kaddr auflisten
find $HOME ! -user $USER -ls  # Rechte im Homeverzeichnis prüfen

Das ist die Fehlermeldung :

Akonadi::PayloadException'
…

Das kann viele Ursachen haben. Fragen wir mal nach ein paar Details:

strace -f -o /tmp/strace.log kaddressbook

Nicht wundern, das ist sehr langsam und produziert locker hunderttausend Zeilen, vermutlich deutlich mehr, da du einen Haufen Schnittstellen aktiv hast. Interessant wäre der Teil ab dem Crash. Die Ausgabe erfolgt in die Datei /tmp/strace.log. Falls strace nicht installiert ist: sudo apt install strace.

Die strace-Ausgabe kann aber warten, falls es bei den obigen Angaben Probleme oder Fragen gibt, sonst wird es schnell unübersichtlich.

Hallo ChickenLipsRfun2ea,

ich dachte ja immer, mein System wäre "top-aktuell", weil ich die Aktualisierungen in Discover immer sofort mache. Das scheint aber nicht der Fall zu sein:

ChickenLipsRfun2eat schrieb:

Dann fangen wir damit an:

1	sudo apt update && sudo apt full-upgrade && sudo apt autoremove && sudo snap refresh # volle Systemaktualisierung

Ich poste jetzt nicht den ganzen Output (wenn nötig hole ich das aber gern nach):

.
.
.
Aktualisierung für 13 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.
.
.
.
Die folgenden Pakete sind zurückgehalten worden:
  grub-efi-amd64-bin grub-efi-amd64-signed python3-software-properties software-properties-common software-properties-qt
Die folgenden Pakete werden aktualisiert (Upgrade):
  libsasl2-2 libsasl2-modules libsasl2-modules-db libsnmp-base libsnmp40 shim-signed tcpdump ubuntu-advantage-tools
8 aktualisiert, 0 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
.
.
.
Alle Snaps sind aktuell.

snap list # alle snaps auflisten

Name               Version          Revision  Tracking       Herausgeber  Hinweise
bare               1.0              5         latest/stable  canonical✓   base
core20             20230126         1822      latest/stable  canonical✓   base
firefox            110.0.1-2        2391      latest/stable  mozilla✓     -
gnome-3-38-2004    0+git.6f39565    119       latest/stable  canonical✓   -
gtk-common-themes  0.1-81-g442e511  1535      latest/stable  canonical✓   -
snapd              2.58.2           18357     latest/stable  canonical✓   snapd

dpkg -l | grep kaddr # debian packages mit Stichwort kaddr auflisten

ii  kaddressbook                                  4:21.12.3-0ubuntu1                          amd64        address book and contact data manager

find $HOME ! -user $USER -ls # Rechte im Homeverzeichnis prüfen }}}

   38981      4 -rwxr--r--   1 root     root           43 Okt 19  2021 ~/uninstaller_brscan-skey
   138976      4 -rwxr--r--   1 root     root           96 Okt 19  2021 ~/uninstaller_brscan4
   138969      4 -rwxr--r--   1 root     root         1295 Okt 19  2021 ~/uninstaller_MFC7360N

Die strace-Ausgabe kann aber warten, falls es bei den obigen Angaben Probleme oder Fragen gibt, sonst wird es schnell unübersichtlich.

Die strace-Ausgabe poste ich später.

Einen schönen Sonntag,

Malefiz

Hallo ChickenLipsRfun2eat,

jetzt kommen die strace-Ausgabe:

ChickenLipsRfun2eat schrieb:

Das kann viele Ursachen haben. Fragen wir mal nach ein paar Details:

strace -f -o /tmp/strace.log kaddressbook

terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: Wrong payload type (requested: sp(0)<KContacts::Addressee>; present: sp(2)<KCalendarCore::Incidence*>)
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kaddressbook path = /usr/bin pid = 4609
KCrash: Arguments: /usr/bin/kaddressbook 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
Unable to find file for pid 4609 expected at "kcrash-metadata/4609.ini"
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
QSocketNotifier: Invalid socket 24 and type 'Read', disabling...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
QSocketNotifier: Invalid socket 17 and type 'Read', disabling...
QSocketNotifier: Invalid socket 18 and type 'Read', disabling...
QSocketNotifier: Invalid socket 19 and type 'Read', disabling...
QSocketNotifier: Invalid socket 20 and type 'Read', disabling...
QSocketNotifier: Invalid socket 25 and type 'Read', disabling...
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
Abgebrochen (Speicherabzug geschrieben)

Nicht wundern, das ist sehr langsam und produziert locker hunderttausend Zeilen, vermutlich deutlich mehr, da du einen Haufen Schnittstellen aktiv hast. Interessant wäre der Teil ab dem Crash. Die Ausgabe erfolgt in die Datei /tmp/strace.log.

Ja, 184988 Zeilen.

Wenn ich in /tmp/strace.log nach "crash" suche, finde ich 12 Übereinstimmungen:

12 Übereinstimmungen (12 überprüft) in geöffneten Dateien gefunden
/tmp/strace.log: 12
 53: 53: 4609  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libKF5Crash.so.5", O_RDONLY|O_CLOEXEC) = 3
26845: 18: 4609  write(2, "KCrash: crashing... crashRecursi"..., 46) = 46
26845: 25: 4609  write(2, "KCrash: crashing... crashRecursi"..., 46) = 46
26845: 37: 4609  write(2, "KCrash: crashing... crashRecursi"..., 46) = 46
26846: 18: 4609  write(2, "KCrash: Application Name = kaddr"..., 67) = 67
26847: 18: 4609  write(2, "KCrash: Arguments: ", 19) = 19
27872: 18: 4609  write(2, "KCrash: Attempting to start /usr"..., 70) = 70
27879: 31: 4609  unlink("/run/user/1000/kcrash_4609" <unfinished ...>
27883: 61: 4609  bind(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/kcrash_4609"}, 110 <unfinished ...>
29027: 53: 4634  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libKF5Crash.so.5", O_RDONLY|O_CLOEXEC) = 3
40061: 44: 4634  statx(AT_FDCWD, "/home/xxx/.cache/kcrash-metadata/4609.ini", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffc93794700) = -1 ENOENT (Datei oder Verze
184888: 31: 4609  unlink("/run/user/1000/kcrash_4609" <unfinished ...>

Ob das jetzt weiter hilft weiß ich nicht, ich kann aber natürlich gern mehr von /tmp/strace.log posten.

Grüße

Malefiz

Malefiz schrieb:

ich dachte ja immer, mein System wäre "top-aktuell"…

Ubuntu ist nie topaktuell. Das ist Teil des Konzeptes. Dazu kommen die phased updates. Es ist aber auch nicht ungepflegt oder sowas.

Da du gekürzt hast, bitte noch

grep -r -v -e ^$ -e ^# /etc/apt/sources.list /etc/apt/sources.list.d/
apt-cache policy kaddressbook

Bei strace käme es auf die letzten Blöcke an. Schwer abzuschätzen, ab wo. Ich würde nach segmentation fault suchen. Oder du packst einfach die letzten zehntausend Zeilen oder so in den PasteService. Mich interessiert eigentlich nur, bei welcher Bibliothek und Methode der falsche Zugriff erfolgt. Oftmals ist es nur eine Kleinigkeit, beispielsweise wenn die Bibliotheksversion nicht zu dem vorkompilierten Paket passt oder andere Abhängigkeiten fehlen (daher die Quellen).

Was die Rechte im Homeverzeichnis angeht: Nicht perfekt, aber für den Fall irrelevant. Bei Gelegenheit nochmal Root-Rechte durchlesen 😉

Parallel können wir auch einen anderen Ansatz verfolgen. Lege einen neuen Benutzer an, richte dort KAddressbook ein und versuche den Fehler zu reproduzieren.

Hallo ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

Da du gekürzt hast, bitte noch

{{{grep -r -v -e ^$ -e ^# /etc/apt/sources.list /etc/apt/sources.list.d/

Hier jetzt die Ausgabe dazu:

/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy main restricted
/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy-updates main restricted
/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy universe
/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy-updates universe
/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy multiverse
/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy-updates multiverse
/etc/apt/sources.list:deb http://de.archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse
/etc/apt/sources.list:deb http://security.ubuntu.com/ubuntu jammy-security main restricted
/etc/apt/sources.list:deb http://security.ubuntu.com/ubuntu jammy-security universe
/etc/apt/sources.list:deb http://security.ubuntu.com/ubuntu jammy-security multiverse

apt-cache policy kaddressbook

kaddressbook:
  Installiert:           4:21.12.3-0ubuntu1
  Installationskandidat: 4:21.12.3-0ubuntu1
  Versionstabelle:
 *** 4:21.12.3-0ubuntu1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        100 /var/lib/dpkg/status

Bei strace käme es auf die letzten Blöcke an. Schwer abzuschätzen, ab wo. Ich würde nach segmentation fault suchen. Oder du packst einfach die letzten zehntausend Zeilen oder so in den PasteService. Mich interessiert eigentlich nur, bei welcher Bibliothek und Methode der falsche Zugriff erfolgt. Oftmals ist es nur eine Kleinigkeit, beispielsweise wenn die Bibliotheksversion nicht zu dem vorkompilierten Paket passt oder andere Abhängigkeiten fehlen (daher die Quellen).

segmentation fault finde ich in der Datei nicht. Die letzten ca. 20.000 Zeilen liegen jetzt im PasteService.

Was die Rechte im Homeverzeichnis angeht: Nicht perfekt, aber für den Fall irrelevant. Bei Gelegenheit nochmal Root-Rechte durchlesen 😉

Ich lese ... 😀

Parallel können wir auch einen anderen Ansatz verfolgen. Lege einen neuen Benutzer an, richte dort KAddressbook ein und versuche den Fehler zu reproduzieren.

Das werde ich machen und mich dann melden.

Vielen Dank für deine Hilfe!

Grüße

Malefiz

Hallo ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

Parallel können wir auch einen anderen Ansatz verfolgen. Lege einen neuen Benutzer an, richte dort KAddressbook ein und versuche den Fehler zu reproduzieren.

Das habe ich jetzt gemacht (mit Systemverwalter Rechten) und einige meiner Kontakte (VCards) in's "neue" KAddressBook importiert und der Fehler / Absturz tritt nicht mehr auf.

Ist dann Neuinstallation von KAddressBook oder Kontact der richtige bzw. einfachste Weg?

Viele Grüße

Malefiz

Hallo!

Ich hänge mal deinen Bericht mit an: 424180

Das eigentliche Problem ist „EBADF (Ungültiger Dateideskriptor)“. Bedeutet, es wird versucht in einer geöffneten Datei zu lesen, die nicht (mehr) existiert oder zugreifbar ist.
Da der Test mit dem neuen Benutzer problemlos funktionierte, ist dein Fehler in der Benutzerkonfiguration zu suchen. KAddressbook neu installieren bringt gar nichts, das sind doch die selben Pakete.

Da KAddressbook keine problematischen Konfigurationsdateien hat (siehe ~/.config/kaddressbookrc und ~/.local/share/kaddressbook/*), wird das Problem bei Akonadi liegen. Da akonadictl fsck das offenbar nicht reparieren konnte gibt es als einfache Möglichkeit nur noch das manuelle Synchronisieren mittels akonadiconsole (ist ne GUI, auch wenn der Name nicht so klingt). In der Liste den Agenten der Kalender/Kontakte auswählen und Synchronisieren klicken. Falls er da auch abschmiert, gäbe es noch löschen und neu machen — entweder den einzelnen Zugang oder die gesamte Konfiguration. Akonadi ist recht komplex und da manuell drin rumpfuschen hat mich noch nie gerettet, auch wenn ich es gerne versuche 😉

Eine weitere Anlaufstelle ist MariaDB/MySql. Falls du damit mal rumexperimentiert hast oder das anderweitig verwendest, könnten wir da noch ansetzen.
Wo verwaltest du deine Kontakte? Lokal oder in Nextcloud, iCloud oder sowas?

Hallo ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

Hallo!

Ich hänge mal deinen Bericht mit an: 424180

Danke, Paste-Service ist neu für mich und ich wusste nicht, wie man das handhabt.

Da KAddressbook keine problematischen Konfigurationsdateien hat (siehe ~/.config/kaddressbookrc und ~/.local/share/kaddressbook/*), wird das Problem bei Akonadi liegen. Da akonadictl fsck das offenbar nicht reparieren konnte gibt es als einfache Möglichkeit nur noch das manuelle Synchronisieren mittels akonadiconsole (ist ne GUI, auch wenn der Name nicht so klingt). In der Liste den Agenten der Kalender/Kontakte auswählen und Synchronisieren klicken. Falls er da auch abschmiert, gäbe es noch löschen und neu machen — entweder den einzelnen Zugang oder die gesamte Konfiguration. Akonadi ist recht komplex und da manuell drin rumpfuschen hat mich noch nie gerettet, auch wenn ich es gerne versuche 😉

Auch akonadiconsole ist Neuland für mich. Ich finde da 2-mal "Persönliche Kontakte", beide mit dem Zusatz "bereit". Leider führt bei beiden "Synchronize all" zu keiner Veränderung.

Löschen und neu machen, wie du vorschlägst ist vielleicht die beste Vorgehensweise. Du meinst Kontact komplett deinstallieren und neu installieren? Reicht das, wenn ich das über Discover mache?

Eine weitere Anlaufstelle ist MariaDB/MySql. Falls du damit mal rumexperimentiert hast oder das anderweitig verwendest, könnten wir da noch ansetzen.

Puh, mit MariaDB/MySq kenne ich mich gar nicht aus.

Wo verwaltest du deine Kontakte? Lokal oder in Nextcloud, iCloud oder sowas?

Die Kontakte, Kalender etc. liegen alle lokal vor und sind gesichert.

Viele Grüße

Malefiz

Ich weiß nicht, was du immer mit dem Reinstallieren willst. Das ändert nichts an der Konfiguration. In Kurzform: Du installierst Pakete aus einem Repo, diese bringen eine systemweite Konfiguration mit, welche normalerweise nicht gelöscht wird. Diese kann mit apt-get --purge PAKET mit entfernt werden. Danach würdest du die selben Pakete erneut installieren und hättest reproduzierbar dein Problem behalten.

In deinem Fall liegt das Problem in der Benutzerkonfiguration, welche niemals von dpkg/apt angefasst wird. Deine Nutzerdaten kannst du einfach manuell selbst löschen. Falls akonadictl vacuum;akonadictl fsck nicht hilft (wovon ich ausgehe, da wir letzteres anfangs probiert haben), wäre das Löschen der nächste Schritt.

Der schnelle Weg zum Löschen wäre

akonadictl stop
rm -rf ~/.{config,local/share}/akonadi

Das kann allerdings schiefgehen, da einige Applikationen den Neustart selbst sofort anfordern können (wie die Uhr, falls die Kalenderintegration aktiv ist). Daher ist der bessere Weg das „von außen“ zu machen. Abmelden, dann auf ein virtuelles Terminal wechseln (Ctrl-Alt-F3 bspw.), dort als Benutzer anmelden und die beiden Ordner löschen. Danach abmelden (Ctrl-D), wieder auf SDDM wechseln (Ctrl-Alt-F1/F7) und anmelden.

Akonadi selbst verwaltet nur Daten, das ist also wie das Löschen eines Cache (abgesehen von ein paar Metadaten, die evtl. verloren gehen). Falls der Fehler also in einer der Quelldateien liegt, bleibt der Fehler bestehen. Sollte das der Fall sein, schreib Bescheid. Dann wirds haarig 😉

Hallo ChickenLipsRfun2eat,

zuerst die gute Nachricht: es funktioniert wieder!

Die zweite gute Nachricht: es gibt keine schlechte.

ChickenLipsRfun2eat schrieb:

Ich weiß nicht, was du immer mit dem Reinstallieren willst. Das ändert nichts an der Konfiguration. In Kurzform: Du installierst Pakete aus einem Repo, diese bringen eine systemweite Konfiguration mit, welche normalerweise nicht gelöscht wird. Diese kann mit apt-get --purge PAKET mit entfernt werden. Danach würdest du die selben Pakete erneut installieren und hättest reproduzierbar dein Problem behalten.

Ich hatte geglaubt, bei einer Reinstallation würde die Konfiguration mit gelöscht. Wenn das nicht der Fall ist, macht Installieren natürlich keinen Sinn.

In deinem Fall liegt das Problem in der Benutzerkonfiguration, welche niemals von dpkg/apt angefasst wird. Deine Nutzerdaten kannst du einfach manuell selbst löschen. Falls akonadictl vacuum;akonadictl fsck nicht hilft (wovon ich ausgehe, da wir letzteres anfangs probiert haben), wäre das Löschen der nächste Schritt.

Der schnelle Weg zum Löschen wäre

akonadictl stop
rm -rf ~/.{config,local/share}/akonadi

Das habe ich nicht gemacht, wegen:

Das kann allerdings schiefgehen,

Deshalb habe ich das "von außen" gemacht, wie von dir vorgeschlagen, und wieder was dazu gelernt.

Akonadi selbst verwaltet nur Daten, das ist also wie das Löschen eines Cache (abgesehen von ein paar Metadaten, die evtl. verloren gehen). Falls der Fehler also in einer der Quelldateien liegt, bleibt der Fehler bestehen. Sollte das der Fall sein, schreib Bescheid. Dann wirds haarig 😉

Das "Haarige" ist mir wohl erspart geblieben 😳

Ich möchte dir sehr für deine Unterstützung danken! Ich finde es außergewöhnlich, wie kompetent und freundlich einem (also mir) in diesem Forum (also von dir) geholfen wird.

Zum Abschluss ein kleineres Problem: meine lokalen Mails sind weg. Ich habe natürlich ein Backup. Kann ich die Mails einfach nach ~/.local/share/local-mail kopieren?

Das gleiche gilt für den Kalender: std.ics gibt es nicht mehr, es ist mir auch nicht gelungen die Datei anzulegen. Z.Z. benutze ich den importierten Kalender, der auf einer anderen Partion liegt.

Viele Grüße

Malefiz

Prima, wenn es wieder läuft. Was die Mails angeht: Holst du die per POP oder IMAP ab? Bei letzterem sollte kein Kopieren nötig sein. Ansonsten kannst du die per KMail einfach per Importfunktion wiederholen. Für den Kalender gilt das selbe. Es spricht aber nichts dagegen einfach die Kopie der Datei zu verwenden, solange du diese dann als Backup sicherst.

Hallo ChickenLipsRfun2eat

ChickenLipsRfun2eat schrieb:

Prima, wenn es wieder läuft.

Ja, finde ich auch 😀

Was die Mails angeht: Holst du die per POP oder IMAP ab? Bei letzterem sollte kein Kopieren nötig sein. Ansonsten kannst du die per KMail einfach per Importfunktion wiederholen.

Da habe ich mich wohl missverständlich ausgedrückt: Für die Mails benutze ich IMAP und das funktioniert auch problemlos. Bestimmte Mails speichere ich lokal auf dem Rechner, in KMail "Lokale Ordner". Diese Mails waren weg. Weil die Default-Einstellung diese Ordners auf ~/.local/share/local-mail zeigt, dachte ich sie gehören dahin. Sie liegen aber in ~/.local/share/akonadi_maildir_resource_0, zumindest bei mir. Jetzt habe ich die Einstellung diese Zugangs geändert und alles ist gut.

Grundsätzlich ist es (für mich) ein Problem rauszukriegen, wo Programme was ablegen, was man bearbeiten kann/darf und wie alles zusammenspielt. Ich beschäftige mich allerdings auch nur dann mit solchen Dingen, wenn etwas nicht so funktioniert, wie es soll. Bis es dann das nächste mal Probleme gibt, habe ich alles wieder vergessen (oder es wurde geändert).

Für den Kalender gilt das selbe. Es spricht aber nichts dagegen einfach die Kopie der Datei zu verwenden, solange du diese dann als Backup sicherst.

Den Kalender lasse ich jetzt in meiner Daten Partition. Da sichere ich regelmäßig.

Noch mal vielen Dank für dein Hilfe!

Viele Grüße

Malefiz