看起来你遇到的核心问题是Tracker的SQLite数据库损坏了，而常规的tracker3 reset命令因为SSH无X11环境、无法建立D-Bus连接而失效。别担心，我们可以绕开D-Bus，直接手动处理损坏的数据库文件来解决问题，具体步骤如下：

步骤1：停止所有Tracker相关进程 #

首先得确保所有Tracker的进程都停止，避免在操作数据库时出现冲突。执行以下命令：

# 查看当前运行的Tracker进程
ps aux | grep tracker
# 强制终止相关进程（如果上面的命令列出了tracker-miner-fs-3、tracker-store-3等）
killall -9 tracker-miner-fs-3 tracker-store-3

步骤2：定位并备份损坏的数据库 #

Ubuntu 22.04中Tracker 3的数据库默认存储在用户的本地目录下，路径是~/.local/share/tracker3/data/。先备份这个目录，防止后续需要恢复：

# 创建备份目录，带日期标识
mkdir ~/.local/share/tracker3/data_broken_$(date +%Y%m%d)
# 移动损坏的数据库到备份目录
mv ~/.local/share/tracker3/data/* ~/.local/share/tracker3/data_broken_$(date +%Y%m%d)/

步骤3：重建Tracker数据库 #

直接删除损坏的数据库文件后，Tracker会在下次启动时自动重建干净的数据库。你可以手动启动Tracker的核心服务来触发重建：

# 启动Tracker存储服务
systemctl --user start tracker-store.service
# 启动文件索引服务
systemctl --user start tracker-miner-fs.service

为什么常规命令失效？ #

你遇到的Cannot autolaunch D-Bus without X11 $DISPLAY错误，是因为tracker3系列命令依赖用户的D-Bus会话，而SSH默认没有启动X11环境，导致无法创建D-Bus连接。手动处理数据库的方法直接绕过了这个依赖，精准解决了数据库损坏的核心问题。

额外注意事项 #

• 如果你的服务器是多用户系统，要确认是哪个用户的Tracker出问题，因为每个用户都有独立的Tracker数据库，需要切换到对应用户执行上述命令。
• 数据库重建后，Tracker会重新索引系统中的文件，这个过程可能会占用一定的磁盘IO，完成后就会恢复正常，不会再出现崩溃日志。

备注：内容来源于stack exchange，提问作者Kevin Keane