Leo
f903a3f53f
leo 回報 Windows daemon 三症狀，查完 ①③ 同根，根在「雲端控制地端」這個設計。 【①③ 真兇】雲端 extractor_config 是**全租戶共用一把 KV** （arcrun:portal.ts:43 portalTenant = worker 層級變數，不分用戶）， 任一處設了 claude → 所有人的 daemon 都收到 claude。沒裝 Claude Code 的機器 FindClaudeBin 失敗 → 每檔萃取 failed、一張卡都沒建；想去 portal 改回 gemini， checkbox 卻恆 disabled（claude_available 恆 false，因 daemon 從未實作 report-capabilities 回報 → daemon_caps KV 永遠空）⇒ 用戶自己解不開。 awindhon 實證：雲端同步成功、Gemini key 有效、零張卡，config.json extractor="claude"。 【leo 裁示】「地端要用什麼模型就在 daemon 上輸入 API Key 設置，而不是雲端設置後 控制地端」「地端先限制 Gemini API Key 配合客戶要求」「雲端就是 Workers AI」。 本次（daemon 端）： - addOrUpdateAccount 不再接受雲端下發的 extractor/gemini_api_key/llm_model， 只收連線欄位。t126「每帳號一份萃取設定」照舊保留——t126 修的是「存在哪一層」， 本次改的是「值從哪來」，兩者正交。 - 托盤新增「AI 設定…」：使用者自己填 Gemini API Key，寫本地 config 後立即生效。 - 萃取一律走 gemini：殘留的 extractor:"claude" 正規化為 gemma；claude 路退役。 ⚠️ 這不是「自動偵測有無 claude」（leo 07-27 已否決的 B 案），是整條路先不支援。 - 清掉隨之死亡的 claude_bin 回寫（死代碼＝錯誤的環境信號）。 - 托盤單一實例（症狀②）：pidfile + 跨平台 processAlive。 mac 之前不多開是借 macOS Launch Services 的巧合，Windows 沒有該層 ⇒ 每點一次多一個 icon。 Unix 用 signal 0（EPERM 也算活著，測試抓到的實際 bug）／Windows 用 OpenProcess+ExitCode。 測試：collector 全綠、tray 全綠。5 個原本用 claude stub 的測試改走**真實 gemma 路** （httptest 替身注入 gemmaBaseURL），不是改斷言充綠；t126②③ 兩案翻轉成 「雲端下發一律被忽略」的回歸守衛；新增 4 案 single-instance。 未送達：本 commit 只到 code，尚未打包出貨；雲端側（刪 portal AI 設定區塊、 extractor 下發、admin/extractor）未動，待部署授權。CP rag-beta 步驟仍為 ◐。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
26 lines
676 B
Go
26 lines
676 B
Go
//go:build !windows
|
|
|
|
package main
|
|
|
|
import (
|
|
"errors"
|
|
"os"
|
|
"syscall"
|
|
)
|
|
|
|
// processAlive 用 signal 0 探測：不真的送訊號，只做「這個 pid 現在存在嗎」的檢查。
|
|
//
|
|
// ⚠️ EPERM 也算活著：行程存在但屬於別的使用者（權限不足送訊號）。
|
|
// 只有 ESRCH（查無此行程）才是真的死了。把 EPERM 當死會讓鎖被錯誤接管 ⇒ 又變成多開。
|
|
func processAlive(pid int) bool {
|
|
p, err := os.FindProcess(pid) // Unix 上這一步不會失敗，真正的判定在 Signal
|
|
if err != nil {
|
|
return false
|
|
}
|
|
err = p.Signal(syscall.Signal(0))
|
|
if err == nil {
|
|
return true
|
|
}
|
|
return errors.Is(err, syscall.EPERM)
|
|
}
|