Gelöst Journal voll mit: "Socket to launch DrKonqi for a systemd-coredump crash was skipped ..."

[wbwb]

auf meinem openSUSE Tumbleweed (momentan 20250414) mit KDE und Graphics Platform Wayland habe ich seit ca. den letzten zwei Upgrades im journal -f einen sich alle paar Sekunden wiederholenden Block aus ~16 gleichlautenden Meldungen

systemd[1234]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).

Weiß jemand was da los ist und wie man das abstellt?

Edit: Vielleicht hilft es noch, dass jeder dieser Blöcke aus Meldungen abgeschloßen wird mit:

systemd[1234]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recently. Will retry later.

Edit:
Ich habe inzwischen meine zypper logs mit meinem journal verglichen und kann deshalb sagen, dass diese Meldungen auf meinem System genau mit einem zypper dup zusammenhängen bei dem ein Update von drkonqi6-6.3.3-1.1.x86_64 -> drkonqi6-6.3.4-1.1.x86_64 stattfand. Ich habe mal einen Bug(?) auf KDE Bugtracking System Main Page eingereicht.

 

[susejunky]

Ich habe mal einen Bug(?) auf KDE Bugtracking System Main Page eingereicht.

... und für Alle, die direkt zu diesem Fehlerbericht wollen, hier der Link.

Auf meinem System

Betriebssystem: openSUSE Tumbleweed 20250414
KDE-Plasma-Version: 6.3.4
KDE-Frameworks-Version: 6.12.0
Qt-Version: 6.9.0
Kernel-Version: 6.14.1-1-default (64-bit)
Grafik-Plattform: X11

zeigt das journal nur die folgenden Meldungen (einmalig!):

> journalctl --no-hostname --full --utc -b 0 | grep drkonqi
Apr 18 12:49:19 systemd[1714]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/drkonqi/sentry-envelopes/*).
Apr 18 12:49:22 systemd[1779]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/user1/.cache/drkonqi/sentry-envelopes/*).
Apr 18 12:49:23 systemd[1779]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/user1/.cache/drkonqi/sentry-envelopes/*).
>
> journalctl --no-hostname --full --utc -b 0 | grep systemd-coredump
Apr 18 12:49:19 systemd[1714]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 12:49:22 systemd[1779]: Listening on Socket to launch DrKonqi for a systemd-coredump crash.
>

Hast Du schon einmal versucht, ob sich das Fehlerbild bei der Verwendung von X11 ändert?

Was ergibt auf Deinem System

systemctl --user status drkonqi-coredump-launcher.socket

Verwendest Du apparmor oder SELinux?

 

[wbwb]

Was ergibt auf Deinem System

systemctl --user status drkonqi-coredump-launcher.socket

Na ja, das dupliziert das was ich schon im OP unter Edit: aus dem journal gepostet hatte, also das er diesen unmet condition check (ConditionUser=!@system). hat und deshalb "nicht will":

systemctl --user status drkonqi-coredump-launcher.socket
○ drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash
     Loaded: loaded (/usr/lib/systemd/user/drkonqi-coredump-launcher.socket; enabled; preset: enabled)
     Active: inactive (dead)
  Condition: start condition unmet at Fri 2025-04-18 16:23:41 CEST; 2s ago
             └─ ConditionUser=!@system was not met
     Listen: /run/user/0/drkonqi-coredump-launcher (SequentialPacket)
   Accepted: 0; Connected: 0;

Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 18 16:23:41 machn systemd[36667]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recent>

Was ist diese ConditionUser=!@system überhaupt?

Hast Du schon einmal versucht, ob sich das Fehlerbild bei der Verwendung von X11 ändert?

Ausprobiert. Keine Änderung.

Auf meinem System ... zeigt das journal nur die folgenden Meldungen (einmalig!): ...

Hmm? So ein paar unmet conditions scheinst Du da ja auch zu haben. Auch die ConditionUser=!@system. Aber aus irgendeinem Grund scheint das bei Dir den drkonqi-coredump-launcher.socket nicht zu stören.

Verwendest Du apparmor oder SELinux?

Bei solchen Fragen werde ich immer nervös. "Verwenden" tue ich auf meinem System sicher eine ganze Menge von Dingen, von denen ich leider keinerlei Ahnung habe. Nachdem ich mal nachgelesen habe, kann ich folgendes sagen:

ls -al /sys/kernel/security/
drwxr-xr-x  5 root root 0 Apr 17 15:13 .
drwxr-xr-x 17 root root 0 Apr 17 15:13 ..
drwxr-xr-x  3 root root 0 Apr 17 15:13 apparmor
lr--r--r--  1 root root 0 Apr 17 15:13 evm -> integrity/evm/evm
lr--r--r--  1 root root 0 Apr 17 15:13 ima -> integrity/ima
drwxr-xr-x  4 root root 0 Apr 17 15:13 integrity
-rw-r--r--  1 root root 0 Apr 17 15:13 lockdown
-r--r--r--  1 root root 0 Apr 17 15:13 lsm
drwxr-xr-x  2 root root 0 Apr 17 15:13 tpm0

Also ja, da gibts ein apparmor directory und keine selinux directory. Außerdem ergibt

~>aa-enabled
Yes

und sestatus ist bei mir nicht installiert.
Ich würde Deine Frage also beantworten mit: Ich "verwende" apparmor.
Und dann? Was hat das mit meinem Problem mit DrKonqi zu tun?

PS: Evtl. bin ich nicht der Einzige mit diesem Problem. Vor 7 Tagen hat jemand im Debian Bug Tracking System unter
Bug#1102651: drkonqi: tries to launch multiple times per second and fails wahrscheinlich genau das Gleiche gepostet und anscheinend auch für die gleiche drkonqi6 Version.

PPS: --no-hostname Nice! Danke.

 

[susejunky]

Ich würde Deine Frage also beantworten mit: Ich "verwende" apparmor.
Und dann? Was hat das mit meinem Problem mit DrKonqi zu tun?

Das kann ich Dir nicht sagen.

Ich habe nur gesehen, dass - seit openSUSE Tumbleweed SELinux als Standard (bei Neu-Installation) verwendet - auf der Mailingliste vermehrt Probleme diskutiert werden, die mit SELinux in Zusammenhang gebracht werden. Würdest Du SELinux verwenden, so wäre es einen Versuch wert zu prüfen, ob SELinux als Fehlerverursacher in Frage käme.

... habe ich seit ca. den letzten zwei Upgrades im journal -f einen sich alle paar Sekunden wiederholenden Block aus ~16 gleichlautenden Meldungen ...

Kannst Du diesen Fehlermeldungszyklus mit

systemctl --user disable drkonqi-coredump-launcher.socket

(danach am besten das System neu starten) stoppen?

 

[wbwb]

Eine nachvollziehbare Erklärung und ein (Quick?)Fix - der jedenfalls für mich bisher funktioniert (= kein Log-flooding mehr von drkonqi) - wurde heute morgen an meinen Post im KDE Bugtracking System (Link) angehängt. Ob der nächste Tumbleweed upgrade das wieder zunichte macht werde ich sehen. Bis dahin setzte ich auf "Gelöst".

Nach diesem Fix ist mir übrigens unklar warum drkonqi6-6.3.4-1.1.x86_64 auf Tumbleweed für manche Nutzer keine derartigen Meldungen im Journal produziert, ohne dass dort vorher an den user spaces gearbeitet wurde.