命令行直接运行 LD_PRELOAD=/usr/lib/libsystemd.so.0 navica...

Criado em: 12 de abril de 2026

Respondido usando GPT-5.4 Thinking por Chat01

Pergunta

命令行直接运行 LD_PRELOAD=/usr/lib/libsystemd.so.0 navicat 可以
但是我编辑快捷方式添加启动命令如下运行还是报错
[Desktop Entry]
Type=Application
Name=Navicat Premium 17
GenericName=Database Development Tool
Icon=navicat-icon
Exec=LD_PRELOAD=/usr/lib/libsystemd.so.0 navicat
Categories=Development;
Keywords=database;sql;

Pensamento

undefined

Pensamento

Clarifying .desktop Exec fixes

To resolve the issue, I might suggest using an absolute path in the Exec field, like Exec=env LD_PRELOAD=... or Exec=/usr/bin/env LD_PRELOAD=... for better compatibility. If needed, mention updating the desktop database or re-logging in. I shouldn't claim too firmly about unsupported behavior but could mention the %U placeholder in case file arguments are needed.

Thought for 27s

Resposta

问题就在 Exec= 这一行。

.desktop 里的 Exec 不是 shell 命令行,而是“可执行程序 + 参数”。规范里还明确说了:可执行程序名会按桌面环境的 $PATH 查找,而且可执行程序名里不能包含 =。所以你写的

ini
Exec=LD_PRELOAD=/usr/lib/libsystemd.so.0 navicat

在快捷方式里不会按“先设置环境变量,再启动 navicat”来执行;它更像是把 LD_PRELOAD=/usr/lib/libsystemd.so.0 当成了要启动的程序,自然就会报错。(Freedesktop Specifications)

直接改成这个:

ini
[Desktop Entry] Type=Application Name=Navicat Premium 17 GenericName=Database Development Tool Icon=navicat-icon Exec=/usr/bin/env LD_PRELOAD=/usr/lib/libsystemd.so.0 navicat Categories=Development; Keywords=database;sql;

更稳一点的话,把 navicat 也写成绝对路径:

ini
Exec=/usr/bin/env LD_PRELOAD=/usr/lib/libsystemd.so.0 /usr/bin/navicat

这样做的原理是:Exec 里的真正可执行文件变成了 /usr/bin/env,后面的 LD_PRELOAD=... 就作为它的参数,由 env 来设置环境变量后再启动 navicat。这也符合 Desktop Entry 规范对 Exec 的要求。(Freedesktop Specifications)

还有一个常见点:如果你命令行里能运行,但桌面快捷方式不行,可能是因为桌面环境使用的 $PATH 和你终端里的不完全一样。规范也说明了,Exec 里如果不是绝对路径,会按桌面环境自己的 $PATH 去找程序。(Freedesktop Specifications)
所以我更建议你最终用这个版本:

ini
Exec=/usr/bin/env LD_PRELOAD=/usr/lib/libsystemd.so.0 /usr/bin/navicat

要是你想更彻底一点,也可以用包装脚本:

/usr/local/bin/navicat-launcher

sh
#!/bin/sh export LD_PRELOAD=/usr/lib/libsystemd.so.0 exec /usr/bin/navicat "$@"

给执行权限后,.desktop 里写:

ini
Exec=/usr/local/bin/navicat-launcher

这通常是最省心的办法。

把你当前 .desktop 文件的完整路径发我,我可以顺手帮你改成可直接用的最终版本。

Pergunta

/usr/bin/env LD_PRELOAD=/usr/lib/libsystemd.so.0 /usr/bin/navicat

还是一样无法运行程序

Pensamento

undefined

Pensamento

undefined

Pensamento

Providing clear and concise troubleshooting steps

The final answer should include citations at the end of paragraphs, without overdoing details like bullets. I'll provide concrete files and commands, and suggest a script solution, explaining why env failed due to potential issues like different working directories or binary location. For debugging, include Terminal=true and log redirection. I'll mention desktop-file-validate and gtk-launch without over-complicating things, focusing on concise steps and reasoning.

Thought for 1m 15s

Resposta

那就别继续硬塞到 Exec= 里了。现在的现象说明:问题大概率已经不是 LD_PRELOAD 这一层,而是桌面启动和你终端启动之间还有差异,比如实际二进制路径、工作目录,或者桌面文件本身有没有被正确解析。Exec 的确只是“程序 + 参数”,PathStartupNotify 这类键也会影响启动行为;另外可以用 desktop-file-validate 检查桌面文件、用 gtk-launch 按桌面规则复现启动。(Freedesktop Specifications)

先按这个最稳方案来。

第一步,先找出 Navicat 的真实路径,在终端执行:

bash
command -v navicat

记下结果。别假设一定是 /usr/bin/navicat

第二步,建一个启动脚本。比如放到 ~/bin/navicat-launcher

sh
#!/bin/sh export LD_PRELOAD=/usr/lib/libsystemd.so.0 # 把下面这一行改成你 command -v navicat 查到的真实路径 APP="/usr/bin/navicat" # 有些 GUI 程序从桌面启动时对工作目录敏感,这里顺手兜一下 cd "$(dirname "$APP")" 2>/dev/null || true exec "$APP" "$@" >>/tmp/navicat.desktop.log 2>&1

然后给权限:

bash
chmod +x ~/bin/navicat-launcher

第三步,把 .desktop 改成只启动这个脚本,不再在 Exec= 里写环境变量:

ini
[Desktop Entry] Type=Application Name=Navicat Premium 17 GenericName=Database Development Tool Icon=navicat-icon Exec=/home/你的用户名/bin/navicat-launcher Path=/home/你的用户名 Categories=Development; Keywords=database;sql; StartupNotify=false

这里有两个点很关键。Path 是标准键,能指定程序的工作目录;StartupNotify 也是标准键,某些不配合启动通知的程序从菜单点开时会表现得像“没启动”。(Freedesktop Specifications)

第四步,先别从菜单点,直接验证这两个东西:

bash
desktop-file-validate /你的/desktop/文件完整路径

desktop-file-validate 就是专门按 Desktop Entry 规范检查 .desktop 文件的。(Arch Linux Man Pages)

再用桌面规则启动一次:

bash
gtk-launch 你的desktop文件名

注意这里填的是 desktop 文件名去掉 .desktop 后缀 的那个 ID。gtk-launch 就是按桌面环境的方式启动应用,不是普通 shell 执行。(https://docs.gtk.org)

第五步,看日志:

bash
cat /tmp/navicat.desktop.log

这个日志很重要。因为现在失败信息大概率被桌面环境吞掉了,真正原因会在这里出现。

你接下来直接把这 4 个结果贴给我,我就能继续往下定位:

bash
command -v navicat desktop-file-validate /你的/desktop/文件完整路径 gtk-launch 你的desktop文件名 cat /tmp/navicat.desktop.log

Pergunta

我是否可以把 export LD_PRELOAD=/usr/lib/libsystemd.so.0 写入我的系统环境变量解决这个问题

Pensamento

Explaining LD_PRELOAD in system env

The user likely wants an answer in Chinese, and it’s probably not necessary to search the web for this. It’s technically possible to export LD_PRELOAD to the system environment, but it's not recommended. It can affect all programs and cause crashes or security issues. Using a user-level wrapper or a desktop-specific environment is safer.

Thought for 10s

Resposta

可以,但不建议这么做。

LD_PRELOAD 是很“猛”的环境变量。你一旦把它写到系统级环境里,很多所有动态链接程序都会先强行加载这个库,结果可能是:

  • 别的软件莫名报错或崩溃
  • 图形程序和终端程序表现不一致
  • 升级后出现更隐蔽的问题
  • 某些程序会直接忽略它,某些程序会被它影响得很严重

所以它适合“只给某一个程序临时加”,不适合当全局系统环境变量

你还要注意一件事:
如果你真写系统环境,很多地方也不能写 export

比如:

/etc/environment 里应写成:

ini
LD_PRELOAD=/usr/lib/libsystemd.so.0

不是:

bash
export LD_PRELOAD=/usr/lib/libsystemd.so.0

但即使写对了,我也不建议你这么配,因为这会影响整个系统会话。

更稳妥的做法只有两个:

方案 1:只给 Navicat 写启动脚本
这是最推荐的。

sh
#!/bin/sh export LD_PRELOAD=/usr/lib/libsystemd.so.0 exec /实际的/navicat/路径 "$@"

然后 .desktop 里写:

ini
Exec=/home/你的用户名/bin/navicat-launcher

方案 2:只给当前用户会话加,而不是系统全局加
例如写到你自己的登录环境里,而不是 /etc/environment
但这依然会影响你这个用户启动的很多程序,还是不如“只给 Navicat 单独脚本”安全。

所以结论是:

  • 能写
  • 不推荐写成系统全局环境变量
  • 最好的办法仍然是给 Navicat 单独做一个 launcher 脚本

你现在这个场景里,真正合适的是“只让 Navicat 带这个 LD_PRELOAD 启动”,不要让整个系统都带上它。

把下面两样发我,我可以直接给你生成一份能用的最终版本:

  1. command -v navicat 的输出
  2. 你的用户名

我会直接给你可复制的 navicat-launcher.desktop 内容。

Pergunta

arch% cat run-navicat.sh
#!/bin/sh
export LD_PRELOAD=/usr/lib/libsystemd.so.0
exec /usr/bin/navicat "$@"

sh run-navicat.sh 可以正常启动navicat

修改启动快捷方式
arch% cat /usr/share/applications/navicat.desktop
[Desktop Entry]
Type=Application
Name=Navicat Premium 17
GenericName=Database Development Tool
Icon=navicat-icon
Exec=/home/hup/opt/navicat/run-navicat.sh
Categories=Development;
Keywords=database;sql;

还是不行

Pensamento

Considering Navicat desktop launch issues

It seems like the issue might be the desktop file not being trusted, especially with the icon path and possibly the working directory. If the script runs from the wrong directory, I’ll need to set the correct Path= in the desktop file or adjust the script. The script might also not be executable, requiring chmod +x. I'll make sure to have the right Exec= command too.

Thought for 15s

Resposta

有两个高概率原因,先看这两个:

1. 你的脚本可能没有可执行权限

你现在是这样验证的:

bash
sh run-navicat.sh

这只能说明“脚本内容没问题”,不能说明脚本本身可被直接执行

.desktop 里这句:

ini
Exec=/home/hup/opt/navicat/run-navicat.sh

要求这个脚本本身必须可执行。

先执行:

bash
chmod +x /home/hup/opt/navicat/run-navicat.sh ls -l /home/hup/opt/navicat/run-navicat.sh

正常应看到有 x 权限。

如果你不想依赖脚本的可执行位,那就把 .desktop 改成:

ini
Exec=/bin/sh /home/hup/opt/navicat/run-navicat.sh

这个很稳。


2. 大概率还缺少工作目录 Path

你在终端里是进入了脚本所在目录后执行的:

bash
sh run-navicat.sh

很多 GUI 程序从桌面启动时,当前工作目录和终端里不一样,有些程序会因此找不到自身资源、插件或配置。

你的情况很像这个。

.desktop 改成下面这样:

ini
[Desktop Entry] Type=Application Name=Navicat Premium 17 GenericName=Database Development Tool Icon=navicat-icon Exec=/bin/sh /home/hup/opt/navicat/run-navicat.sh Path=/home/hup/opt/navicat Terminal=false StartupNotify=false Categories=Development; Keywords=database;sql;

同时把脚本也顺手改成更稳一点:

sh
#!/bin/sh cd /home/hup/opt/navicat || exit 1 export LD_PRELOAD=/usr/lib/libsystemd.so.0 exec /usr/bin/navicat "$@"

我建议你直接这样做

脚本

sh
#!/bin/sh cd /home/hup/opt/navicat || exit 1 export LD_PRELOAD=/usr/lib/libsystemd.so.0 exec /usr/bin/navicat "$@"

然后:

bash
chmod +x /home/hup/opt/navicat/run-navicat.sh

desktop 文件

ini
[Desktop Entry] Type=Application Name=Navicat Premium 17 GenericName=Database Development Tool Icon=navicat-icon Exec=/bin/sh /home/hup/opt/navicat/run-navicat.sh Path=/home/hup/opt/navicat Terminal=false StartupNotify=false Categories=Development; Keywords=database;sql;

如果还不行,马上这样排错

把脚本改成带日志:

sh
#!/bin/sh cd /home/hup/opt/navicat || exit 1 export LD_PRELOAD=/usr/lib/libsystemd.so.0 exec /usr/bin/navicat "$@" >/tmp/navicat.log 2>&1

然后从菜单点一次,再看:

bash
cat /tmp/navicat.log

如果日志还是空,再检查这两个:

bash
ls -l /home/hup/opt/navicat/run-navicat.sh desktop-file-validate /usr/share/applications/navicat.desktop

我现在的判断

按你给的信息,最可能的问题不是 LD_PRELOAD,而是这两个之一:

  • .desktop 直接执行脚本,但脚本没有 +x
  • 从桌面启动时工作目录不对,所以 Navicat 起不来

你先按我上面那版改,成功率很高。

把这三条输出贴我,我可以继续帮你一眼定位:

bash
ls -l /home/hup/opt/navicat/run-navicat.sh cat /usr/share/applications/navicat.desktop cat /tmp/navicat.log

Pergunta

arch% vim run-navicat.sh
arch% cat run-navicat.sh
#!/bin/sh
cd /home/hup/opt/navicat || exit 1
export LD_PRELOAD=/usr/lib/libsystemd.so.0
exec /usr/bin/navicat "$@"
arch% chmod +x /home/hup/opt/navicat/run-navicat.sh
arch% cat /usr/share/applications/navicat.desktop
[Desktop Entry]
Type=Application
Name=Navicat Premium 17
GenericName=Database Development Tool
Icon=navicat-icon
Exec=/bin/sh /home/hup/opt/navicat/run-navicat.sh
Categories=Development;
Keywords=database;sql;

arch% cat /tmp/navicat.log
cat: /tmp/navicat.log: 没有那个文件或目录
arch% ls -l /home/hup/opt/navicat/run-navicat.sh
desktop-file-validate /usr/share/applications/navicat.desktop
-rwxr-xr-x 1 hup hup 115 4月12日 11:17 /home/hup/opt/navicat/run-navicat.sh
arch%

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

Finalizing response with appropriate citations

I need to include citations for factual statements. Since I already searched for certain facts, I should cite relevant statements, especially around desktop-file-validate, syntax checking, and descriptors. I’ll mention the precedence search order for desktop files: user entries go to /.local/share/applications by default, and system directories are searched after.

Clarifying conclusion and possible causes

The strongest conclusion here isn’t "LD_PRELOAD still wrong"; it’s likely that "your modified desktop entry isn’t the one being launched." Evidence: desktop-file-validate raised no issues, and the shape of the Exec command is valid. Possible causes include another desktop entry being active or the use of DBusActivatable=true. For next steps, consider creating a local override instead of modifying system files.

Thought for 1m 8s

Resposta

现在基本可以下结论了:

问题大概率已经不在 LD_PRELOAD 或脚本本身,而在于“桌面环境实际启动的不是你刚改的这份 .desktop 文件”。
因为:

  • desktop-file-validate 是专门用来检查 .desktop 语法是否合法的工具,而你这里没有看到任何报错输出,说明至少这份文件语法层面没有明显问题。(Arch Manual Pages)
  • Desktop Entry 规范允许 Exec 写成“可执行程序 + 参数”,所以你现在这句
    Exec=/bin/sh /home/hup/opt/navicat/run-navicat.sh
    这种写法本身是合法思路。(Freedesktop.org Specifications)
  • /tmp/navicat.log 根本没生成,说明菜单点击后很可能压根没有执行到这个脚本。这是最关键的信号。

我建议你不要继续改 /usr/share/applications/navicat.desktop,直接改成用户级覆盖。XDG Base Directory 规范把用户级数据目录定义为 $XDG_DATA_HOME,默认就是 ~/.local/share;而 ArchWiki 也把应用 desktop entry 的常见位置列为 ~/.local/share/applications/usr/share/applications。这意味着用用户自己的 ~/.local/share/applications/navicat.desktop 做覆盖,通常比直接改系统文件更稳。(Freedesktop.org Specifications)

按这个顺序做:

1)先把 desktop 文件放到用户目录

bash
mkdir -p ~/.local/share/applications cp /usr/share/applications/navicat.desktop ~/.local/share/applications/navicat.desktop

然后改成:

ini
[Desktop Entry] Type=Application Name=Navicat Premium 17 GenericName=Database Development Tool Icon=navicat-icon Exec=/bin/sh /home/hup/opt/navicat/run-navicat.sh Path=/home/hup/opt/navicat Terminal=false StartupNotify=false Categories=Development; Keywords=database;sql;

2)把脚本改成带日志

sh
#!/bin/sh cd /home/hup/opt/navicat || exit 1 export LD_PRELOAD=/usr/lib/libsystemd.so.0 exec /usr/bin/navicat "$@" >/tmp/navicat.log 2>&1

然后确认权限:

bash
chmod +x /home/hup/opt/navicat/run-navicat.sh

3)不要先点菜单,先用 desktop 方式直接启动

gtk-launch 会按 desktop file 的方式启动应用,参数是 desktop 文件名对应的应用 ID。(Ubuntu Manpages)

你的文件叫 navicat.desktop,就执行:

bash
gtk-launch navicat

然后立刻看日志:

bash
cat /tmp/navicat.log

还要重点检查的一件事:有没有“另一份” navicat.desktop

很多时候你改的是 /usr/share/applications/navicat.desktop,但实际生效的是别处的同名文件,或者菜单里引用的是另一份 launcher。先找一遍:

bash
find ~/.local/share/applications /usr/local/share/applications /usr/share/applications -name '*navicat*.desktop' -print

再看它们的 Exec

bash
grep -R '^Exec=' ~/.local/share/applications /usr/local/share/applications /usr/share/applications | grep navicat

再补一个高级坑:DBusActivatable=true

如果真正被启动的那份 desktop 文件里有 DBusActivatable=true,实现可以忽略 Exec,转而走 D-Bus 激活;这种情况下你改 Exec= 也不会生效。GNOME 文档和 Desktop Entry 规范都提到了这一点。(developer.gnome.org)

所以再查一下:

bash
grep -R '^DBusActivatable=' ~/.local/share/applications /usr/local/share/applications /usr/share/applications | grep navicat

如果查到是 true,就把实际生效的那份 desktop 文件里这一行删掉或改成:

ini
DBusActivatable=false

现在最值得你做的最短路径

直接跑这 4 条:

bash
mkdir -p ~/.local/share/applications cp /usr/share/applications/navicat.desktop ~/.local/share/applications/navicat.desktop gtk-launch navicat cat /tmp/navicat.log

如果还是没日志,再把这两条结果贴出来:

bash
find ~/.local/share/applications /usr/local/share/applications /usr/share/applications -name '*navicat*.desktop' -print grep -R '^DBusActivatable=' ~/.local/share/applications /usr/local/share/applications /usr/share/applications | grep navicat

我下一步就能直接判断到底是“启动的不是这份 desktop”,还是“被 D-Bus 激活绕过了 Exec”。

Pergunta

arch 安装输入法配置好后重启有如下警告 如何处理
检测到设置了 GTK_IM_MODULE 和 QT_IM_MODULE 而且 Wayland 输入法前端正在正常工作。推荐使用 Wayland 输入法前端。更多信息请参见 https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#KDE_Plasma

Pensamento

undefined

Pensamento

Thought for 15s

Resposta

这是 提醒,不是报错。意思是:你现在是在 Wayland 会话 下,而且 Fcitx 5 的 Wayland 前端已经正常工作,这时再全局设置 GTK_IM_MODULEQT_IM_MODULE,反而会覆盖掉原生 Wayland 输入法通道。Fcitx 官方和 ArchWiki 都更推荐:在 Wayland 下优先用原生 text-input,GTK/Qt 不显式指定 IM module;这些变量主要留给 XWayland / 传统 X11 程序。(Fcitx)

你可以这样处理:

  1. 删掉全局环境里的这两项
    • GTK_IM_MODULE=...
    • QT_IM_MODULE=...

常见位置有:

  • /etc/environment
  • ~/.pam_environment
  • /etc/profile
  • ~/.profile
  • ~/.xprofile
  • ~/.config/environment.d/*.conf
  1. 通常保留这一项就够了
bash
XMODIFIERS=@im=fcitx

这主要是给旧的 X11 / XWayland 程序兜底。ArchWiki 也建议在 Wayland 下把 IM module 主要留给 XWayland 应用使用。(Arch Wiki)

  1. 如果你是 KDE Plasma Wayland 到: 系统设置 → 虚拟键盘 → 选择 “Fcitx 5”

    Fcitx 官方对 KWin/Plasma Wayland 的说明也是这么配。(Fcitx)

可以参考一个更合适的 Wayland 配置思路:

bash
# 不设置 # GTK_IM_MODULE # QT_IM_MODULE # 保留给旧程序 XMODIFIERS=@im=fcitx

如果你偶尔有个别程序输入不了,再单独处理:

  • 原生 Wayland Chromium/Electron:通常用 Wayland IM 启动参数解决
  • 跑在 XWayland 下的应用:再按需给它单独加 GTK_IM_MODULE=fcitx 之类的环境变量。Fcitx 官方对这两类场景做了区分说明。(Fcitx)

最简单的结论就是:

  • Wayland + Plasma/Fcitx5 正常时:删掉 GTK_IM_MODULEQT_IM_MODULE
  • 保留或按需使用 XMODIFIERS=@im=fcitx
  • 在 KDE 里启用虚拟键盘 Fcitx 5

把你现在的 /etc/environment~/.config/environment.d/ 相关内容贴出来,我可以直接告诉你该删哪几行。

Pergunta

向日葵在wayland arch kde 上 字体很小
如何处理

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

Concise troubleshooting steps with commands

To solve the scaling issue, first check the "Legacy applications (X11)" setting under "Scaled by system." If the text becomes usable but blurry, it confirms an XWayland issue. Then, try custom desktop wrappers depending on the app type (Qt, GTK, Electron), using commands like QT_SCALE_FACTOR, GDK_SCALE, or --force-device-scale-factor. Choose one approach. Test with the Electron flag first, then try the Qt settings. Since the user edited .desktop files before, they’re likely familiar with this.

Thought for 1m 30s

Resposta

这是 KDE Wayland 下典型的旧应用/XWayland 缩放问题。ArchWiki 现在的说明很直接:Plasma 在 Wayland 里对 X11 应用有两种模式,“Scaled by the system” 会把窗口放大但可能发糊,“Apply scaling themselves” 会更清晰,但不支持 HiDPI 的应用就会显得很小。你的向日葵现象很像后一种。(Arch Wiki)

先用最省事的办法试:

  1. 打开 系统设置 → 显示与监视器 → 显示配置
  2. 在页面底部找到 Legacy applications (X11)
  3. 把它从 Apply scaling themselves 改成 Scaled by the system

如果改完以后向日葵字体立刻正常、只是略糊,就基本坐实它是这个问题。ArchWiki 也明确说了,这个模式是“通用但会模糊”,另一个模式则会让没适配 HiDPI 的应用变小。(Arch Wiki)

如果你不想影响别的程序,最好只给向日葵单独加缩放。按应用类型分别试,一次只试一种

ini
# 如果它像 Qt 程序 Exec=env QT_ENABLE_HIGHDPI_SCALING=1 QT_SCALE_FACTOR=1.5 sunloginclient
ini
# 如果它像 GTK 程序 Exec=env GDK_SCALE=2 GDK_DPI_SCALE=0.5 sunloginclient
ini
# 如果它像 Electron/Chromium 程序 Exec=sunloginclient --force-device-scale-factor=1.5

ArchWiki 对这三类办法都有对应说明:Qt 可用 QT_ENABLE_HIGHDPI_SCALING / QT_SCALE_FACTOR,GTK 可用 GDK_SCALE / GDK_DPI_SCALE,Electron 类程序可加 --force-device-scale-factor。(Arch Wiki)

.desktop 时,建议不要改 /usr/share/applications/...,而是复制到用户目录再改,避免升级被覆盖。做法可以是:

bash
mkdir -p ~/.local/share/applications cp /usr/share/applications/sunloginclient.desktop ~/.local/share/applications/

然后编辑 ~/.local/share/applications/sunloginclient.desktop 里的 Exec=。缩放值先试 1.251.51.75。如果你是 4K 屏,通常 1.5 比较常见。(Arch Wiki)

如果你用的是 125% / 150% 这类分数缩放,那在 Wayland 下旧 X11 程序本来就容易出现“小但清晰”和“大但模糊”二选一的情况;这是 Plasma/XWayland 的已知取舍,不只是向日葵一个软件。(Arch Wiki)

最稳的结论是:

  • 想省事:把 Legacy applications (X11) 改成 Scaled by the system
  • 想只修向日葵:改它自己的 .desktop,给 Exec= 加缩放参数
  • 还不满意:登录 Plasma on X11 会更容易兼容这类旧程序的 DPI/缩放表现,因为 Wayland 下这类兼容层问题还没完全消失。(Arch Wiki)

把这条命令的输出贴给我,我可以直接告诉你该用 Qt、GTK 还是 Electron 那一套:

bash
grep '^Exec=' /usr/share/applications/*sunlogin*.desktop ~/.local/share/applications/*sunlogin*.desktop 2>/dev/null

Pergunta

还有个问题 很多程序在关闭的时候会报错
PID: 887323 (sunloginclient)
UID: 1000 (hup)
GID: 1000 (hup)
Signal: 11 (SEGV)
Timestamp: Sun 2026-04-12 18:07:32 CST (5s ago)
Command Line: /opt/sunlogin/bin/sunloginclient --mod=remote_plugin --pluginname=desktop --hostname=arch --remote_hostname=mini --permission=-1 --fastconnectid=SEvLd2k7zyY= --verify_code=T2nbyO9tOD4= --remoteid=ar5cck/bDcCflrNS1EuF9g== --level=Jy2LylD15lA= --level_name=OZmcwgTyDhqGMpdCpWp4sA== --os=WsJJL3no8U16B+6+r3ECqQ== --os_version=kHhLrMJZturrEDPDWTUwwA== --main_hwnd=H3jtZmX5Qd8= --control=SEvLd2k7zyY= --projection=48ebPErDP0g= --support_camera=SEvLd2k7zyY= --support_file=SEvLd2k7zyY= --remote_width=48ebPErDP0g= --remote_height=48ebPErDP0g= --certificate=SEvLd2k7zyY= --sound=nmHj4LXiipY= --userid=9X3wLKx0gBY= --seat=48ebPErDP0g= --pilot=48ebPErDP0g= --clientid=wk5WEOjejucrCBBwiWeEOjrWI9xnDtGYxew55Kh45Av40JYpPkIAlQ== --udx=48ebPErDP0g= --watermark_content= --watermark_transparency=X3Mj4B0su7c= --seatid= --mac=ZkMrnzkNL0pEFil2SyvpwePHmzxKwz9I --local_fastcode=e0HbP5MEiwOhUt6wILeCew== --windows_account= --scan_projection=48ebPErDP0g= --account=Vy89XHposFrC9Wvsju0Aaw== --mobile= --login_type=48ebPErDP0g= --remote_platform=8LQ6DEV8ObE= --free_times=rHbvSr0Hm+M= --free_minutes=48ebPErDP0g= --free_try=48ebPErDP0g= --local_channel_count=SEvLd2k7zyY= --access_token=eXpVG92qG4C4APN9UVMyqBD6W0R+QLehYuPT31IFKpzda9ZVlAfBktG5F+vQMYA+vGZVP8CQoLWDIZAYGjfz1JPD7i2mF5TAC/7P2YlKv6C9s/1VYo/0WXpuT7c178Q+IAUvj95QztoDBKEHnAF6jcaDWixrc5O/6vcms+o5A8p6qtngUsiS/XCsyXWA2SzQgD+fcXU5g4sTTlXsEzG/+Dt+KHJcOOgrWWh1U2hrSzzjVOnnesyyX87rHIENf0++BbHPKBT8wiZ2PbxBocGsefN2Zpr0REf5RvPsstZyrsilvWjYj+Ja9LHywupuEXKLgfqytjzwi5SynceRzlXxw9+46Se+X2o9qZleKX3j6WUShuEkNhbJLPfnYLYEYKjR8X/gPXQ9yfrsoigXn3r4IwlXb0lvnk2SXbV/t0WZHD9Hft4W0kMOpKfUV7S0noRYQe2un5GOH9lTI8EkDrkzY+PD2jEZLYrRuynGEUUGfUqewVG8JwZRKOOVIRhbgLgeJryx2jkEenUDmoSzwSmxs9BJbxhLa7baTYr4ORLWyxS12Pm8bLEzAmgiTeX/gkcL9KTy0Bwu4dHnp+qa1dgc9MAJEzhV/xU4MzYjOuUp1po/lODdFeaTQ+ClKT4eT/Rji8BDEOsKxXMcbQAxQcpNjw== --auto_login=SEvLd2k7zyY= --features=YvAqZb2/twg1q9ViU52AmQW0qV9C2ET6Sa+16VSoFk13ya2CkXX81ycO+3eQWH2svJbpV0ygYp8b4wInNMayGvnGh/wfKnMtr2k1xCEfXTQFjJdLy/NCit9wE/oBc3+yayLfzpFUxjdIS8jzgaNuDNzW5DYsEqn7m3QEHX2Ko3u8lulXTKBin9VG1MwWPuFdvJbpV0ygYp/4FArFE2Bk/Dkf1+HgLw3YXQRfONZ3V1c5H9fh4C8N2MhIFXSPeOUVvJbpV0ygYp/JkqqC7XzRXB2oHGi6ZZzx9Qz1xHUl9ErEczUrMoFXNsg6hgaK9cqQzMLOws4FbZdqGF0bofTqTINcPB8TqySXRPICRdmIyoNVFEdXlQiJc491ZIY40SnkBUqD79UgatCQ2I0TMgS5ie3GLUi7MDnWP5ttDYfSKmAXMfGAtR6pS2fDYMhrppPGvAuBdeurMBj2k2Hc1NKwPnFCkn6lrq8PfqKa2FdOgtqBng1gAzFDLUZ2WEUUUggxMWZgZI5O8SCLuFNxcJqeliiQr/UQBF8oqyQKUrlpPGGLf+AaJ0E1tcS35pWlt2HW9eq0q4Uvtra8lulXTKBin4oFl2KUMP3j0SQUpV9DbKaopJpQWJaiHahENBPnPpzGIH+ojlDkMocnQIULRysIn74e2OyEToXrhvrC9B9YYqCY2MHHpnNHBl4sDzmp1xA+VoxlUxCXUG9loICcvT1WU/AmYfMTkhKCMQ6t8J29FcM/m20Nh9IqYJd/YU1GcRlPlFo+hDTCUYC8lulXTKBin4e8YFIlw+Xm3wd4Xc7D6EQpzfnd8y1mjg== --client_api_addr=DqWmVJt9eH4dXz3bXRGc9tOLu1/wlKyjHwK0SkFRWd4= --free_disconnnect_time=48ebPErDP0g= --remote_hostdesc= --sid=4HOvL2fTmJMzyBjJ67Osng== --is_open_cloudrecord=48ebPErDP0g= --host_username=r9Z34yWenfI=
Executable: /opt/sunlogin/bin/sunloginclient
Control Group: /user.slice/user-1000.slice/[email protected]/app.slice/app-[email protected]
Unit: [email protected]
User Unit: [email protected]
Slice: user-1000.slice
Owner UID: 1000 (hup)
Boot ID: 4877f7f40ac540bdb24378ae23de0b68
Machine ID: 06ede30e83654d7db9cf9df40d835589
Hostname: arch
Storage: /var/lib/systemd/coredump/core.sunloginclient.1000.4877f7f40ac540bdb24378ae23de0b68.887323.1775988452000000.zst (present)
Size on Disk: 5.7M
Message: Process 887323 (sunloginclient) of user 1000 dumped core.

text
Stack trace of thread 887323: #0 0x000000000045045f n/a (/opt/sunlogin/bin/sunloginclient + 0x5045f) #1 0x0000000001534955 n/a (/opt/sunlogin/bin/sunloginclient + 0x1134955) #2 0x00000000014c37ba n/a (/opt/sunlogin/bin/sunloginclient + 0x10c37ba) #3 0x000000000153c3ae n/a (/opt/sunlogin/bin/sunloginclient + 0x113c3ae) #4 0x00007fb76e906f4d n/a (libglib-2.0.so.0 + 0x5ef4d) #5 0x00007fb76e908607 n/a (libglib-2.0.so.0 + 0x60607) #6 0x00007fb76e908815 g_main_context_iteration (libglib-2.0.so.0 + 0x60815) #7 0x00007fb76ebead2b gtk_main_iteration (libgtk-3.so.0 + 0x1ead2b) #8 0x0000000000464035 n/a (/opt/sunlogin/bin/sunloginclient + 0x64035) #9 0x0000000000e217a3 n/a (/opt/sunlogin/bin/sunloginclient + 0xa217a3) #10 0x0000000000e2121b n/a (/opt/sunlogin/bin/sunloginclient + 0xa2121b) #11 0x0000000000466767 n/a (/opt/sunlogin/bin/sunloginclient + 0x66767) #12 0x0000000000449ea4 n/a (/opt/sunlogin/bin/sunloginclient + 0x49ea4) #13 0x000000000044a3c4 n/a (/opt/sunlogin/bin/sunloginclient + 0x4a3c4) #14 0x00007fb76df186c1 n/a (libc.so.6 + 0x276c1) #15 0x00007fb76df187f9 __libc_start_main (libc.so.6 + 0x277f9) #16 0x0000000000446a6e n/a (/opt/sunlogin/bin/sunloginclient + 0x46a6e) Stack trace of thread 887326: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76e00b595 epoll_wait (libc.so.6 + 0x11a595) #4 0x0000000000460388 n/a (/opt/sunlogin/bin/sunloginclient + 0x60388) #5 0x000000000045fc86 n/a (/opt/sunlogin/bin/sunloginclient + 0x5fc86) #6 0x000000000045f66c n/a (/opt/sunlogin/bin/sunloginclient + 0x5f66c) #7 0x000000000045e851 n/a (/opt/sunlogin/bin/sunloginclient + 0x5e851) #8 0x0000000000aa53f0 n/a (/opt/sunlogin/bin/sunloginclient + 0x6a53f0) #9 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #10 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887354: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887355: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887359: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887356: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887353: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887391: #0 0x00007fb76e00906d syscall (libc.so.6 + 0x11806d) #1 0x00007fb76e934dee g_cond_wait (libglib-2.0.so.0 + 0x8cdee) #2 0x00007fb76e8ce22d n/a (libglib-2.0.so.0 + 0x2622d) #3 0x00007fb76e8ce29d g_async_queue_pop (libglib-2.0.so.0 + 0x2629d) #4 0x00007fb76e4b351c n/a (libpangoft2-1.0.so.0 + 0xc51c) #5 0x00007fb76e93e4fc n/a (libglib-2.0.so.0 + 0x964fc) #6 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #7 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887392: #0 0x00007fb76e00906d syscall (libc.so.6 + 0x11806d) #1 0x00007fb76e934dee g_cond_wait (libglib-2.0.so.0 + 0x8cdee) #2 0x00007fb76e8ce22d n/a (libglib-2.0.so.0 + 0x2622d) #3 0x00007fb76e93e9c7 n/a (libglib-2.0.so.0 + 0x969c7) #4 0x00007fb76e93e4fc n/a (libglib-2.0.so.0 + 0x964fc) #5 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #6 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887378: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df8fc1b n/a (libc.so.6 + 0x9ec1b) #4 0x0000000000ed1a27 n/a (/opt/sunlogin/bin/sunloginclient + 0xad1a27) #5 0x0000000000e95573 n/a (/opt/sunlogin/bin/sunloginclient + 0xa95573) #6 0x0000000000e94ecd n/a (/opt/sunlogin/bin/sunloginclient + 0xa94ecd) #7 0x0000000000ed1699 n/a (/opt/sunlogin/bin/sunloginclient + 0xad1699) #8 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #9 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887358: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887395: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76dffe2f6 ppoll (libc.so.6 + 0x10d2f6) #4 0x00007fb76e908734 n/a (libglib-2.0.so.0 + 0x60734) #5 0x00007fb76e9089c7 g_main_loop_run (libglib-2.0.so.0 + 0x609c7) #6 0x00007fb76e7ee6a4 n/a (libgio-2.0.so.0 + 0x1196a4) #7 0x00007fb76e93e4fc n/a (libglib-2.0.so.0 + 0x964fc) #8 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #9 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887393: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76dffe2f6 ppoll (libc.so.6 + 0x10d2f6) #4 0x00007fb76e908734 n/a (libglib-2.0.so.0 + 0x60734) #5 0x00007fb76e908815 g_main_context_iteration (libglib-2.0.so.0 + 0x60815) #6 0x00007fb76e908862 n/a (libglib-2.0.so.0 + 0x60862) #7 0x00007fb76e93e4fc n/a (libglib-2.0.so.0 + 0x964fc) #8 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #9 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887400: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76e008ac1 __select (libc.so.6 + 0x117ac1) #4 0x0000000000bdcc44 n/a (/opt/sunlogin/bin/sunloginclient + 0x7dcc44) #5 0x0000000000bd8210 n/a (/opt/sunlogin/bin/sunloginclient + 0x7d8210) #6 0x0000000000bde11b n/a (/opt/sunlogin/bin/sunloginclient + 0x7de11b) #7 0x0000000000aa53f0 n/a (/opt/sunlogin/bin/sunloginclient + 0x6a53f0) #8 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #9 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887357: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df8468c n/a (libc.so.6 + 0x9368c) #3 0x00007fb76df86e5e pthread_cond_wait (libc.so.6 + 0x95e5e) #4 0x00007fb7665eca1e n/a (libgallium-26.0.4-arch1.1.so + 0x5eca1e) #5 0x00007fb7665a1dbd n/a (libgallium-26.0.4-arch1.1.so + 0x5a1dbd) #6 0x00007fb7665ec95d n/a (libgallium-26.0.4-arch1.1.so + 0x5ec95d) #7 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #8 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887401: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76e00b595 epoll_wait (libc.so.6 + 0x11a595) #4 0x0000000000460388 n/a (/opt/sunlogin/bin/sunloginclient + 0x60388) #5 0x000000000045fc86 n/a (/opt/sunlogin/bin/sunloginclient + 0x5fc86) #6 0x000000000045f66c n/a (/opt/sunlogin/bin/sunloginclient + 0x5f66c) #7 0x000000000045e851 n/a (/opt/sunlogin/bin/sunloginclient + 0x5e851) #8 0x0000000000aa53f0 n/a (/opt/sunlogin/bin/sunloginclient + 0x6a53f0) #9 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #10 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887576: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76e00b595 epoll_wait (libc.so.6 + 0x11a595) #4 0x0000000000460388 n/a (/opt/sunlogin/bin/sunloginclient + 0x60388) #5 0x000000000045fc86 n/a (/opt/sunlogin/bin/sunloginclient + 0x5fc86) #6 0x000000000045f66c n/a (/opt/sunlogin/bin/sunloginclient + 0x5f66c) #7 0x000000000045e851 n/a (/opt/sunlogin/bin/sunloginclient + 0x5e851) #8 0x0000000000aa53f0 n/a (/opt/sunlogin/bin/sunloginclient + 0x6a53f0) #9 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #10 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 887396: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76dffe2f6 ppoll (libc.so.6 + 0x10d2f6) #4 0x00007fb76e908734 n/a (libglib-2.0.so.0 + 0x60734) #5 0x00007fb76e908815 g_main_context_iteration (libglib-2.0.so.0 + 0x60815) #6 0x00007fb75b3767be n/a (libdconfsettings.so + 0x77be) #7 0x00007fb76e93e4fc n/a (libglib-2.0.so.0 + 0x964fc) #8 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #9 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) Stack trace of thread 891959: #0 0x00007fb76df8ff32 n/a (libc.so.6 + 0x9ef32) #1 0x00007fb76df8439c n/a (libc.so.6 + 0x9339c) #2 0x00007fb76df843e4 n/a (libc.so.6 + 0x933e4) #3 0x00007fb76e008ac1 __select (libc.so.6 + 0x117ac1) #4 0x0000000000bdcc44 n/a (/opt/sunlogin/bin/sunloginclient + 0x7dcc44) #5 0x0000000000bd8210 n/a (/opt/sunlogin/bin/sunloginclient + 0x7d8210) #6 0x0000000000bde11b n/a (/opt/sunlogin/bin/sunloginclient + 0x7de11b) #7 0x0000000000aa53f0 n/a (/opt/sunlogin/bin/sunloginclient + 0x6a53f0) #8 0x00007fb76df8797a n/a (libc.so.6 + 0x9697a) #9 0x00007fb76e00b2bc n/a (libc.so.6 + 0x11a2bc) ELF object binary architecture: AMD x86-64

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

Mentioning global tweaks and environment variables

If many apps are crashing, it's worth considering whether global tweaks like modifying /etc/ld.so.preload or LD_PRELOAD could be the cause. I could mention undoing any global changes to these variables first. Also, Fcitx environment variables probably aren’t causing the segfault, though unusual environment mismatches could play a role in GTK app crashes.

Providing a concise solution for app crashes

The log indicates an app crash (sunloginclient) on exit, with a SIGSEGV error. This appears to be related to the app’s graphics teardown, likely caused by proprietary binary incompatibilities on newer systems. To address this:

  1. Remove global environment injections like LD_PRELOAD and any Wayland-related GTK/QT modules.
  2. For Sunlogin, try running it in XWayland with the GDK_BACKEND=x11 command.

Thought for 2m 28s

Resposta

这份日志里,崩的是 sunloginclient 这个进程本身,不是整台系统一起崩。Signal: 11 (SEGV) 是典型段错误;而你贴出来的调用栈顶部主要在 /opt/sunlogin/bin/sunloginclient 自己,下面才是 libgtk-3.so.0libglib-2.0.so.0 和 Mesa 的 libgallium 线程,所以更像是应用退出阶段的图形/事件循环清理崩溃,不是 KDE 或内核主因。再结合贝锐自己以前的文档承认过 Linux 上会受 Wayland 显示服务器影响,而 Arch/Wayland 侧本来就会让很多传统 X11 程序通过 XWayland 兼容层运行,这类专有闭源程序在 Plasma Wayland 上“能用但退出时崩”并不罕见。(service.oray.com)

先说结论:
这更像是向日葵 Linux 客户端和你当前 Wayland/GTK/Mesa 组合的兼容性问题。
最稳的处理顺序不是继续折腾系统,而是:

  1. 先撤掉任何全局注入
  2. 把向日葵强制跑在 XWayland/X11 后端
  3. 如果还崩,再测试软件渲染,确认是不是 Mesa/GPU 退出路径的问题
  4. 实在追求稳定,就给向日葵单独用 X11 会话

你前面讨论过 LD_PRELOAD。这里我要特别提醒:如果你后来真的把 LD_PRELOAD 做成了全局环境,或者写进了 /etc/ld.so.preload,先撤掉。动态链接器文档明确说了,/etc/ld.so.preloadsystem-wide effect,会让指定库对系统执行的所有程序生效;而 LD_PRELOAD 本身也是在程序启动前预加载共享库。这个东西只适合单独给 Navicat 这种个别程序用,不适合全局挂着。(Arch Manual Pages)

因为你的栈里明确出现了 libgtk-3.so.0,所以向日葵这边优先按 GTK 应用 处理。GTK 官方文档支持用 GDK_BACKEND 选择后端,而 ArchWiki 也说明在 Wayland 下,旧的 X11 应用通常会通过 XWayland 兼容层运行。你可以先直接这样测试一次:

bash
GDK_BACKEND=x11 /opt/sunlogin/bin/sunloginclient

如果这样退出时不再报错,基本就坐实是 Wayland 后端/兼容层问题。(https://docs.gtk.org)

你前面提到“字体很小”,而 GTK 也支持单独调缩放。GTK 文档里有 GDK_SCALEGDK_DPI_SCALE 的说明,所以可以把“字体小”和“关闭崩”一起合并到一个 launcher 里处理:(https://docs.gtk.org)

bash
#!/bin/sh unset LD_PRELOAD unset GTK_IM_MODULE unset QT_IM_MODULE export GDK_BACKEND=x11 export GDK_SCALE=2 export GDK_DPI_SCALE=0.5 exec /opt/sunlogin/bin/sunloginclient "$@"

然后把向日葵的 .desktop 改成:

ini
Exec=/bin/sh /home/hup/opt/sunlogin/run-sunlogin.sh

如果 强制 X11 后端以后仍然退出崩溃,下一步就测是不是 GPU/Mesa 路径。Mesa 官方文档明确写了:LIBGL_ALWAYS_SOFTWARE=true 会强制软件渲染,LIBGL_DEBUG=verbose 会打印调试信息,MESA_LOG_FILE_AUTO=1 会自动在 /tmp 生成日志。你的调用栈里正好也有 libgallium 线程,所以这一步很有价值。(Mesa 3D Documentation)

你可以这样跑:

bash
LIBGL_ALWAYS_SOFTWARE=true \ GDK_BACKEND=x11 \ MESA_LOG_FILE_AUTO=1 \ /opt/sunlogin/bin/sunloginclient

判断方式很简单:

  • 这样就不崩了:大概率是 GPU/Mesa/硬件加速退出路径的问题。
  • 这样还崩:更像是向日葵客户端自己的退出 bug。

如果你只是想稳定使用,不想继续深挖,最现实的方案还是:向日葵单独尽量走 X11 路径,或者直接登录 Plasma on X11。贝锐自己早期的 Linux 文档就是把“切到 Xorg/X11”作为 Wayland 相关问题的官方解决办法;虽然他们后来宣传“在 Linux 的 Wayland 协议下也能稳定远控”,但这更像是“已支持”,不代表在 Arch 这种滚动发行版 + 新 Mesa + Plasma Wayland 的组合上没有边角兼容问题。(service.oray.com)

你现在最值得立刻执行的是这三步:

bash
grep -R "LD_PRELOAD\|GTK_IM_MODULE\|QT_IM_MODULE" \ /etc/environment ~/.pam_environment ~/.profile ~/.xprofile ~/.config/environment.d /etc/profile.d 2>/dev/null test -f /etc/ld.so.preload && cat /etc/ld.so.preload GDK_BACKEND=x11 /opt/sunlogin/bin/sunloginclient

把这三条输出贴出来,我可以直接帮你判断到底是:

  • 全局环境污染
  • 向日葵的 Wayland/XWayland 兼容问题
  • 还是 Mesa/GPU 退出路径的问题。

Pergunta

我的输入法自定义词组做了如下配置 但是 shijian 这个配置每生效 其他的生效了
heis,1=[email protected]
hup,1=[email protected]
hup,2=[email protected]
shijian,1=yearyear-month_mm-dayddday_dd fullhour:minute:minute:second
shijian,2=yearyearmonth_mmdayddday_ddfullhourminuteminutesecond

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

undefined

Pensamento

Analyzing why "shijian" doesn't work

I think I have enough information to cite the code, but I still need to figure out why "shijian" doesn't work. It might be because the candidate isn’t on the first page due to many normal candidates, or perhaps issues with custom phrase order. It could also be a problem with how "shijian" is split into smaller phrases. I need to look into the syntax and dynamic variables like month_mm, day_dd, or fullhour to check if they’re being evaluated correctly. I'll check customphrase.cpp in the repository for more insights.

Thought for 1m 5s

Resposta

问题不在 shijian 这个拼音本身,而在 动态变量前面少了 #

Fcitx 5 拼音自定义词组里:

  • 只有当词条值 # 开头 时,才会进入“动态求值”模式。源码里 isDynamic() 就是检查 value().starts_with("#");否则会把内容当普通静态字符串原样返回。(GitHub)
  • 你用到的这些变量名本身都是支持的,比如 yearmonth_mmday_ddfullhourminutesecond。(GitHub)
  • 自定义词组键名像 shijian 这种全字母写法也是合法的,查找还是精确匹配。(GitHub)

所以你现在这两行:

ini
shijian,1=$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,2=$year$month_mm$day_dd$fullhour$minute$second

应改成:

ini
shijian,1=#$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,2=#$year$month_mm$day_dd$fullhour$minute$second

更稳一点也可以写成带花括号的形式:

ini
shijian,1=#${year}-${month_mm}-${day_dd} ${fullhour}:${minute}:${second} shijian,2=#${year}${month_mm}${day_dd}${fullhour}${minute}${second}

你前面那几个邮箱词条能生效,是因为它们本来就是静态文本,不需要 #。而时间这两条属于动态词条,没有 # 就不会展开变量。(GitHub)

改完后如果你是直接编辑文件,重启一下 fcitx5 再试。
如果仍然看不到候选,再把你的自定义词组文件完整内容和文件路径贴出来,我帮你继续查。

Pergunta

修改配置后正常了
如何设置自定义词组在候选框中的位置

Pensamento

undefined

Pensamento

undefined

Pensamento

Providing concise answer with citations

The order field controls placement in the candidate list, with smaller positive values earlier (1 = top, 2 = second). The engine subtracts 1 and stable-sorts before merging custom candidates with normal pinyin. Custom candidates are constructed first, and then merged via stable sort, keeping them before normal candidates when in the same order. Citations needed.

Clarifying order behavior and display control

Duplicates with the same order preserve file order due to stable sorting during normalization and later sorting of candidates. If custom entries share the same order, their position follows the initial loaded order. The "固定为候选框第 N 行" setting isn't fixed universally, as deduplication and hidden candidates influence display. The order field controls priority, not absolute display. For citations, check lines L2-L5 in the source.

Thought for 1m 11s

Resposta

可以,自定义词组在候选框里的位置就是靠中间那个数字控制的

ini
编码,顺序=内容

例如:

ini
shijian,1=#$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,2=#$year$month_mm$day_dd$fullhour$minute$second

这里的含义是:

  • 1:尽量排到最前
  • 2:尽量排到第 2 个
  • 3:尽量排到第 3 个

Fcitx 读取后会按这个 order 升序排序,数字越小越靠前;0 是无效值。源码里还能看到,展示候选时会把自定义词组的顺序转换成 order - 1 再参与整体候选排序。(GitHub)

你可以这样写:

ini
shijian,1=#$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,2=#$year$month_mm$day_dd$fullhour$minute$second mail,1=[email protected] mail,2=[email protected] mail,3=[email protected]

还有两个细节:

  1. 相同编码下,同样的 order 会按文件里的先后顺序保留,因为这里用的是稳定排序。(GitHub)
  2. 这个位置是“优先级位置”,不是 100% 绝对固定行号。因为 Fcitx 还会把普通拼音候选、云拼音、拼写纠错等一起合并去重后再排序;如果有重复词或额外候选,显示位置可能会被挤动。(GitHub)

实用建议是:

  • 想置顶就用 ,1
  • 第二个就用 ,2
  • 不常用的放 ,5,6 以后

比如你这个时间:

ini
shijian,1=#$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,2=#$year$month_mm$day_dd$fullhour$minute$second

就是最合适的写法。

你要是愿意,我可以顺手给你整理一份更完整的 Fcitx5 自定义词组模板,带邮箱、日期、时间、手机号、常用签名。

Pergunta

我想固定放到第五个位置上

Pensamento

Thought for 10s

Resposta

可以写成 ,5

ini
shijian,5=#$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,6=#$year$month_mm$day_dd$fullhour$minute$second

但要注意,这不是“绝对固定显示在第 5 个”,而是把它的排序优先级设为第 5 档。Fcitx 读取自定义词组后会按 order 从小到大排序;0 是无效值。(GitHub)

同时,拼音引擎在生成候选时,会把自定义词组以 result.order() - 1 的位置优先级插入候选列表里。也就是说,5 对应的是“尽量放在前 5 附近的那个优先级”,不是无论什么情况都死死占住第 5 个。(GitHub)

所以实操上:

  • 想让它尽量第 5 个:用 shijian,5=...
  • 想让第二个时间格式排在后面一点:用 shijian,6=...

例如:

ini
shijian,5=#$year-$month_mm-$day_dd $fullhour:$minute:$second shijian,6=#$year$month_mm$day_dd$fullhour$minute$second

如果你发现它有时跑到第 4 或第 6,通常不是你写错了,而是因为前面还有别的普通拼音候选、联想候选或重复去重后的结果一起参与排序。(GitHub)

你这个需求里,最接近“固定第五个” 的写法就是 ,5
但 Fcitx 5 这里没有给你一个“锁死在候选框第 5 位”的独立配置项。(GitHub)

Compartilhar esta Q&A