服务：KDE 的崩溃上报器

一句话结论

开机弹出的 drkonqi 报错，不是 nix 配置错误、不是启动顺序问题，也不是你的应用/硬件在崩——是 KDE 的崩溃上报器（drkonqi 6.6.6）自身有缺陷：它被「每次登录补捞存量 core」的机制反复喂进来，交接失败就自杀，自杀又留下新 core，形成自产自销的闭环。

账本：161 个 core 的真实分布（2026-10-11 实测）

分类                     数量   体积     时间窗                  性质
历史（桌面环境折腾期）    12 个  265 MB   10-06 ~ 10-10 21:14    对应「桌面起不来」那段，已结束
  其中 plasmashell 4 个 240 MB；kwin_wayland 4 个 22 MB；xdg-desktop-portal-kde 10 个 13 MB
噪声（上报器自崩）        89 个  123 MB   10-07 15:58 ~ 10-11 12:35  仍在持续，每次开机重来
证据（真实应用崩溃）      47 个  106 MB   10-09 14:11 ~ 10-10 22:46  已停止
  其中 Hermes 46 个（非 Qt 程序，不写 kcrash 纸条）；trilium 1 个
其它（X 等小工具）        13 个   25 MB   —                        噪音级
合计                     161 个  519.7 MB

今天的 16 个 core（10:06 八次 + 12:35 八次）全部是 drkonqi 自己——今天没有任何应用/驱动/内核的新崩溃。

噪音链路（上游自带的单元 + 实测时间戳）

生产噪音的是这两个用户级单元（由 kdePackages.drkonqi 提供，NixOS 用 systemd.packages 整套挂上）：

$D/share/systemd/user/drkonqi-coredump-pickup.service        ← 每次登录必跑的「补捞存量」
  After=plasma-core.target
  Requires=drkonqi-coredump-launcher.socket
  ExecStart=…/drkonqi-coredump-processor --settle-first --pickup --uid %U
  WantedBy=plasma-core.target
  RuntimeMaxSec=30 minutes        ← 跑起来后最长 30 分钟内持续捡 core

$D/share/systemd/user/drkonqi-coredump-launcher.socket       ← 接收端（Accept=yes，MaxConnections=16）
  ListenSequentialPacket=/run/user/%U/drkonqi-coredump-launcher
  # 上游自己在这份单元的注释里写着：This is a bit problematic.

闭环（2026-10-11 本次开机实测）：
  12:35:11  开机，launcher.socket 监听
  12:35:26  pickup 起 → 把存量 core 交给 launcher（一次 8 个）
  12:35:27  launcher[5385-5396]: Not exactly one fd passed by systemd. Quel malheur!  → 全部 qFatal 自杀
            ⇒ 自杀各自留下真 core ⇒ 池子多了 8 个
  12:36:50  pickup 仍在跑：launcher[9709] 开始处理 pid 5390（就是刚才那批自己人）
            ⇒ 会话内自食，直到 30 分钟上限或捡不到新的
  下一次登录：池子只增不减（drkonqi-coredump-cleanup.timer 是 inactive，从未启用）⇒ 再来一遍

三个候选的裁决

候选                     裁决     判据
nix 配置错误             不成立   这些单元全部来自上游包 kdePackages.drkonqi/share/systemd/user/，
                                  NixOS 只用 systemd.packages 整套挂上（plasma6.nix:288）；
                                  /etc/nixos 里没有一行碰过它；上游自己在 socket 里写了 This is a bit problematic.
启动顺序问题             不成立   顺序是正确且刻意的：pickup Requires=launcher.socket、After=plasma-core.target
                                  ⇒ 先监听再交货。错不在先后，在交接的内容
程序（drkonqi 6.6.6）缺陷  成立   ① 用 sd_listen_fds 要求「恰好 1 个 fd」，实际不等于 1 ⇒ 不跳过不重试，直接 qFatal
                                  ② 找不到 kcrash-metadata/<app>.<bootid>.<pid>.ini 也 qFatal
                                     ——而它自己从不写这张纸条（本不该处理自己的 core）
                                  ③ drkonqi-coredump-cleanup.timer 从未启用 ⇒ 存量池永不枯竭

这条链分三段，切断时动的是哪一段

段                        对应单元                                          动它 =
记录（写 core）           systemd-coredump@（系统侧，systemd 自带）          不碰：真实崩溃照旧记录，coredumpctl 照旧能查
处置/提醒（弹窗+上报）     launcher.socket/@.service → drkonqi GUI             切断 = 屏蔽提醒
                          → drkonqi-sentry-postman
补捞存量（噪音起点）       drkonqi-coredump-pickup.service（每次登录）        切断 = 掐断自产自销的起点

结论：切断 pickup+launcher 是「移除触发点 + 屏蔽提醒」，不是修 bug、也不是切断噪音记录；
      真实崩溃的记录一点没少，反而自产的假记录消失。

两种处置的选择对照（本轮未实施，仅记录）：
项目                  只屏蔽 pickup（推荐）               pickup + socket 全切
登录时回捞存量         停                              停
崩溃时弹窗提醒         保留                            失去
崩溃时上报             保留                            失去
残余噪音               非 Qt 程序崩溃时仍可能让其自杀一次   无

附带证据：~/.cache/kcrash-metadata/ 里只有 dolphin/plasmashell 的纸条 ⇒ 只有 Qt/KDE 程序能走到弹窗那步；
          Electron 类（Hermes/Chrome/Trilium）本来就没有纸条 ⇒ 它们的「提醒」现状已是坏的（一律变成 launcher 自杀）。

实际发生的两个真故障（都在存量 core 里，均已停止）

故障 A：Hermes 桌面在无 X 环境下被反复拉起（10-10 22:00 ~ 22:46，39 个 core，每 ~60 秒一次）
  证据：desktop-relaunch.log 与 core 同 pid（22655，SIGSEGV）
    [22655:…] ERROR:ozone_platform_x11.cc:256] Missing X server or $DISPLAY
    [22655:…] ERROR:aura/env.cc:257] The platform failed to initialize.  Exiting.
  性质：在「没有 X server / $DISPLAY 的会话」里反复启动 Electron 桌面 ⇒ 一初始化就退出；
        那串 SIGILL/SIGTRAP/SIGSEGV 是 Chromium 该初始化失败路径的 trap/abort，不是内存或硬件问题
  「每 60 秒」的来源：不是定时器（用户 timers 只有 tmpfiles-clean 与 drkonqi 两个），
        日志由 hermes desktop 启动器写出 ⇒ 当时那串重启桌面应用的尝试，22:49 已恢复、现已无循环
  风险：肇事二进制就是现在在跑的那个（mtime 10-06，md5 d32ce6631a68ae35c7f9655523a690de）
        ——但触发它的是运行环境（无 X），不是它自身的 bug

故障 B：桌面起不来那一波（10-10 21:14，49 个 core）
  参与：plasmashell×2 / ksecretd / kiconfinder6 / xdg-desktop-portal-kde / trilium / drkonqi
  性质：与「服务：x11/wayland/plasma 在注销和重启下的不同行为」YzwTPiLBkfhb 记录的那段是同一件事，已结束

现状与复发条件

健康判据（2026-10-11 实测）：DISPLAY=:0、XDG_SESSION_TYPE=x11、plasma-plasmashell 与 plasma-kwin_x11 均 active
今天有无新故障：无（今天 16 个 core 全是 drkonqi 自己）
复发条件：① 每次登录 Plasma 时 drkonqi 闭环必然来一轮（只要存量 core 还在）
          ② 若在无 X/$DISPLAY 的会话里再起 Hermes 桌面 ⇒ 故障 A 会原样重演
未坐实（未实测）：为什么 sd_listen_fds 拿到的 fd 数不等于 1。已确认不是顺序问题、不是我们的配置，
                  但要坐实到「systemd 传参 vs 程序取值」哪一侧，需要抓 drkonqi-coredump-launcher@ 实例的
                  StandardInput/Sockets 属性与一次带调试的失败现场。

自查命令（可自行复核）

coredumpctl list --no-pager                                    # 全部 core 清单
coredumpctl list --no-pager | awk '$2 == "2026-10-11"'        # 只看今天的
coredumpctl info <pid> --no-pager                              # 单个 core 的回溯与信号
journalctl -b 0 --no-pager | grep -i 'Not exactly one fd'       # 本次开机的自杀证据
journalctl -b 0 --no-pager | grep -iE 'pickup|drkonqi'          # 补捞与处理链的活动
systemctl --user is-active drkonqi-coredump-launcher.socket     # 接收端是否在监听
systemctl --user is-active drkonqi-coredump-cleanup.timer      # 清理器是否启用（本机 inactive）
du -sh /var/lib/systemd/coredump                                # 存量占用
ls /var/lib/systemd/coredump | wc -l                            # 存量个数

相关笔记

  • 「服务：x11/wayland/plasma 在注销和重启下的不同行为」YzwTPiLBkfhb（故障 B 的同一段）
  • 「显卡：780M 集显外接屏幕启动黑屏问题」oDmTnSoJUTax（桌面起不来时期的外接屏线索）