[BUG]: [Linux] AnythingLLM Desktop AppImage hangs indefinitely on “Pulling query_engine” behind SOCKS5 proxy (Prisma client download fails)

该报错通常发生在 Linux 环境下通过 SOCKS5 代理启动 AnythingLLM 桌面版 AppImage 时,应用卡在“Pulling query_engine”阶段且界面永不出现。优先排查代理 IP 是否拼写错误,并尝试用 LD_LIBRARY_PATH= 清空环境变量启动,或手动预置

快速结论:该报错通常发生在 Linux 环境下通过 SOCKS5 代理启动 AnythingLLM 桌面版 AppImage 时,应用卡在“Pulling query_engine”阶段且界面永不出现。优先排查代理 IP 是否拼写错误,并尝试用LD_LIBRARY_PATH=清空环境变量启动,或手动预置 Prisma 引擎文件跳过下载。

适用环境:Ubuntu 系 Linux 发行版(内核支持 FUSE);AnythingLLM 桌面版 AppImage(最新官方版本);Intel Haswell iGPU(触发 MESA-INTEL Vulkan 警告);需要 SOCKS5 代理(报告中的代理地址同时出现 192.68.80.228192.168.80.228,可能存在拼写不一致)。

最快修复方案:暂无经过完整验证的一步修复方案。可优先尝试手动预置 Prisma 引擎文件(评论中给出的 workaround),并确认代理 IP 正确、清除 LD_LIBRARY_PATH 后启动。

注意事项:手动预置方案依赖引擎目录中已存在对应文件,如果仍然挂起则说明问题可能不在引擎下载环节;评论者明确表示桌面应用调用的是系统 curl 而非 Electron fetch,因此代理本身是受支持的,问题更可能出在子进程环境差异,而非代理处理机制的缺陷。

问题场景

用户通过终端启动 AnythingLLMDesktop.AppImage(执行时附加 --disable-gpu),在 SOCKS5 代理环境下应用挂起。日志显示应用在下载 Prisma 的 libquery_engine.so.node 后不再输出任何内容,GUI 不出现,系统监视器中出现多个残留进程。用户在磁盘上发现 AppImage 挂载正常、AppArmor 未拦截、权限和磁盘空间均充足。

报错原文

[PrismaHelper] Pulling query_engine for debian-openssl-3.0.x from remote. {
  remote: 'https://binaries.prisma.sh/all_commits/61e140623197a131c2a6189271ffee05a7aa9a59/debian-openssl-3.0.x/libquery_engine.so.node.gz'
}

(Note: After this line, no further logs appear until manual termination).

原因分析

可能原因有两个,均为维护者在回复中提出的假设:

一是代理 IP 拼写不一致。Issue 标题和正文中同时出现 192.68.80.228192.168.80.228 两个地址,如果用户在启动 AppImage 的 shell 中实际设置的是错误 IP,curl 会因 SOCKS5 连接失败而静默挂起,直到手动终止。这可以解释为什么手动 curl 测试成功(手动测试时所处的 shell 代理正确)而 AppImage 子进程挂起(继承的代理环境变量可能不同或拼错)。

二是 AppImage 的 LD_LIBRARY_PATH 泄漏。AppImage 运行时会导出指向 FUSE 挂载点的 LD_LIBRARY_PATH,这可能导致 AppImage 调用系统 curl 时加载了捆绑的动态库,进而卡死。

维护者同时指出:应用没有重试循环,“Pulling query_engine”每启动一次只打印一次,日志中出现多行说明是多次启动的累积,这也解释了为什么会堆积多个残留进程。此外,下载流程本身没有超时设置,连接卡住时启动过程会无限阻塞——维护者认为这是需要改进的健壮性问题,但不是代理处理机制本身的缺陷。

环境排查

  • 在启动 AppImage 的同一个 shell 中执行 echo $https_proxy,确认代理 IP 是否为 192.168.80.228(注意不要拼错为 192.68.80.228)。
  • 检查 LD_LIBRARY_PATH 是否被 AppImage 导出;可尝试启动时手动清空该变量。
  • 确认目录 ~/.config/anythingllm-desktop/storage/.prisma/engines/ 可写且磁盘空间充足。
  • 手动 curl 测试目标 URL 是否能正常通过 SOCKS5 代理返回 HTTP 200:curl -v https://binaries.prisma.sh/all_commits/61e140623197a131c2a6189271ffee05a7aa9a59/debian-openssl-3.0.x/libquery_engine.so.node.gz -o /dev/null

解决步骤

  1. 修正代理 IP 拼写:在终端中先执行 echo $https_proxy 确认代理地址与实际 SOCKS5 服务端一致;如果是 192.68.80.228,请改为 192.168.80.228 后重新启动 AppImage。
  2. 清空 LD_LIBRARY_PATH 启动:执行 LD_LIBRARY_PATH= ./AnythingLLMDesktop.AppImage,观察是否仍卡在“Pulling query_engine”。
  3. 手动预置 Prisma 引擎文件(可优先尝试):在终端中执行以下命令,下载引擎并解压到应用预期目录,使应用跳过下载流程直接启动:
    DIR=~/.config/anythingllm-desktop/storage/.prisma/engines/61e140623197a131c2a6189271ffee05a7aa9a59
    mkdir -p "$DIR" && cd "$DIR"
    BASE=https://binaries.prisma.sh/all_commits/61e140623197a131c2a6189271ffee05a7aa9a59/debian-openssl-3.0.x
    curl -L "$BASE/libquery_engine.so.node.gz" -o libquery_engine-debian-openssl-3.0.x.so.node.gz
    curl -L "$BASE/schema-engine.gz" -o schema-engine-debian-openssl-3.0.x.gz
    gunzip libquery_engine-debian-openssl-3.0.x.so.node.gz schema-engine-debian-openssl-3.0.x.gz
    chmod +x libquery_engine-debian-openssl-3.0.x.so.node schema-engine-debian-openssl-3.0.x
  4. 验证预置后是否正常启动:上述命令执行完成后,重新运行 AppImage,应用应不再访问 binaries.prisma.sh 直接进入界面;若仍然挂起,请收集新的终端输出并提交到 Issue,说明问题可能不在引擎下载环节。

验证方法

应用能顺利打开 GUI 且终端不再长时间停留在“Pulling query_engine”处;残留的僵尸进程不再累积。如果执行了手动预置后应用仍挂起,检查终端是否有新的报错输出(例如 curl 写入失败或引擎校验错误),并以此作为后续排查方向。

参考来源

Mintplex-Labs/anything-llm #6133

GamsGo AI

AI 工具推荐

想把多个 AI 模型放在一个入口?

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。

这个方案解决了吗?

celebrityanime
celebrityanime
文章: 19120

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注