High Altitude Oolong

2025/10/10

GNOME Terminal 啟動逾時問題

問題描述

當從 xterm 啟動 gnome-terminal 時，會顯示以下錯誤訊息：

Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached

雖然最終 gnome-terminal 會成功啟動，但需要等待約 25 秒的逾時時間。

原因：fcitx5 重複啟動導致的競態條件（Race Condition）

這個問題是由 im-config 和 systemd 雙重啟動 fcitx5 所引起的競態條件。

完整時間軸

10:33:15 - 使用者工作階段啟動（systemd --user）
10:33:17 - im-config 自動啟動 fcitx5（過早！）
10:33:17 - fcitx5 透過 D-Bus 觸發 xdg-desktop-portal
10:33:17 - xdg-desktop-portal 嘗試啟動 xdg-desktop-portal-gnome
10:33:17 - xdg-desktop-portal-gnome 啟動失敗
         - 錯誤：「graphical-session.target is inactive」
         - 錯誤：「Dependency failed for xdg-desktop-portal-gnome.service」

10:33:19 - GNOME Shell 完成啟動（2 秒後）
10:33:19 - graphical-session.target 變為 ACTIVE
10:33:19 - 如果 fcitx5 在此時啟動，portal 就能正常運作

--- 經過 84 秒 ---

10:34:43 - 使用者從 xterm 啟動 gnome-terminal
10:34:43 - gnome-terminal（GTK 應用程式）嘗試存取 xdg-desktop-portal-gnome
10:34:43 - Portal 後端仍未執行（從未從早期失敗中恢復）
10:34:43 - D-Bus 嘗試啟動 portal，但發生逾時
10:35:08 - 25 秒逾時後，terminal 仍然啟動

細節

im-config 框架透過 ~/.xinputrc 設定在 X11 session 初始化時自動啟動 fcitx5
fcitx5 在登入後約 2 秒時過早啟動（在 graphical-session.target 就緒前）
fcitx5 立即透過 D-Bus 請求 xdg-desktop-portal
xdg-desktop-portal 嘗試載入 xdg-desktop-portal-gnome 後端
xdg-desktop-portal-gnome.service 有嚴格的相依性：Requisite=graphical-session.target
在該時刻（10:33:17），graphical-session.target 尚未就緒
服務因未滿足的相依性而啟動失敗
2 秒後（10:33:19），graphical-session.target 變為就緒（GNOME Shell 完成載入後）
Portal 服務從未重試 - 保持失敗狀態
當啟動 gnome-terminal 時，它嘗試存取 portal
D-Bus 啟動在 25 秒後逾時

為什麼會有重複啟動的問題？

系統中存在兩種啟動 fcitx5 的機制：

im-config（傳統方式）：透過 ~/.xinputrc 在 X session 早期啟動
systemd service（現代方式）：透過 fcitx5.service 在 graphical-session.target 後啟動

im-config 的啟動時機太早，導致 fcitx5 在 graphical-session.target 就緒前就請求 portal，觸發競態條件。

重點：這是一個時序問題，不是效能問題。解決方案是禁用 im-config 自動啟動，改用 systemd 服務在正確時機啟動 fcitx5。

解決方案

方案 1：正確的永久修復（推薦，已驗證有效）

步驟 1：禁用 im-config 自動啟動 fcitx5

im-config -n none

這會將 ~/.xinputrc 設定為 run_im none，停止過早啟動 fcitx5。

步驟 2：建立 systemd 使用者服務來管理 fcitx5

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/fcitx5.service << 'EOF'
[Unit]
Description=Fcitx5 Input Method
Documentation=man:fcitx5(1)
PartOf=graphical-session.target
After=graphical-session.target
Wants=graphical-session.target

[Service]
Type=simple
ExecStart=/usr/bin/fcitx5
ExecStartPost=/usr/bin/dbus-update-activation-environment --systemd GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx
Restart=on-failure
RestartSec=3

[Install]
WantedBy=graphical-session.target
EOF

systemctl --user daemon-reload
systemctl --user enable fcitx5.service

說明：

After=graphical-session.target 確保 fcitx5 在圖形工作階段就緒後才啟動
ExecStartPost 設定必要的環境變數讓應用程式能使用 fcitx5
這完全避免了競態條件，因為 fcitx5 會在正確的時機啟動

步驟 3：重新啟動系統

systemctl reboot

登入後，fcitx5 會在 graphical-session.target 就緒後自動啟動，gnome-terminal 將立即開啟。

方案 2：繞過 D-Bus Factory（臨時快速修復，不建議長期使用）

gnome-terminal --disable-factory

這會完全避免 D-Bus 啟動機制。可以在 ~/.bashrc 或 ~/.zshrc 中建立別名：

alias gnome-terminal='gnome-terminal --disable-factory'

缺點：會失去 terminal server 的功能，每次都會啟動新的 terminal 實例。

方案 3：等待工作階段初始化完成（暫時性緩解）

登入後等待 5 秒以上再啟動 gnome-terminal。這不是真正的解決方案，只是避開競態條件的時間窗口。

測試

套用方案 1 後（禁用 im-config 並使用 systemd 服務）：

重新啟動系統
登入後檢查啟動順序：journalctl --user -b 0 | grep -E "fcitx5|graphical-session.target|xdg-desktop-portal"
應該看到：
- graphical-session.target 先就緒
- fcitx5.service 在之後啟動
- xdg-desktop-portal-gnome 成功啟動
立即嘗試啟動 gnome-terminal
應該不會出現 25 秒的逾時，terminal 會立即開啟

修復前後對比

修復前（問題狀態）：

10:33:17 - im-config 啟動 fcitx5 (graphical-session.target 未就緒)
10:33:17 - xdg-desktop-portal-gnome 啟動失敗
10:33:19 - graphical-session.target 就緒 (太晚了)
10:34:43 - 啟動 gnome-terminal
10:35:08 - 25 秒逾時後 terminal 才開啟

修復後（正常狀態）：

13:03:34 - graphical-session.target 就緒
13:03:34 - systemd 啟動 fcitx5.service
13:03:34 - xdg-desktop-portal-gnome 成功啟動
13:03:39 - gnome-terminal 立即開啟 (無逾時)

結論

這個問題的根本原因是 im-config 和 systemd 雙重啟動機制造成的競態條件。im-config 在 X session 初始化早期就啟動 fcitx5，此時 graphical-session.target 尚未就緒，導致 fcitx5 觸發的 xdg-desktop-portal-gnome 因相依性未滿足而啟動失敗。Portal 服務從未重試，因此當 gnome-terminal 稍後嘗試使用 portal 時，就會發生 25 秒的 D-Bus 逾時。

正確的解決方案是禁用 im-config 自動啟動，改用 systemd 使用者服務在 graphical-session.target 就緒後才啟動 fcitx5。這確保了正確的啟動順序，完全避免競態條件。

系統資訊：

作業系統：Ubuntu Linux
桌面環境：GNOME 46.2
GNOME Terminal：3.52.0
輸入法：fcitx5

2025/9/20

新酷音 : Chewing, ibus 和 fcitx5

ubuntu 24.04 default 的輸入管理器是 iBus.
但是iBus在新酷音有點問題，就是不能記住目前的 input mode (Eng/Chinese)，以 Excel 來說，換 cell 輸入法就被 reset 成中文。

fctix5 就沒這個問題。
選 fctix5 然後 apt install fcitix5-chewing 之後，在應用城市會出現企鵝的程式 fctix5-config，右邊那邊選 Chewing 按兩下就可以了。

25/10/10 update:

結果每次開機gnome-termial 都要等 5 min 之後才開得起來，但是 Xtermin 沒有問題。
請 claude-code 找問題，果然是...

2025/9/14

claude code router

claude-code 的 api 不是和其他人一樣的 openai (?) 的方式，所以就有人做了一個 gateway，把 anthropic 呼叫轉為openai 呼叫，同時把回應也改成 anthropic api 回應。
當然，這是用 reverse engineering 做的。

claude-code-router

claude code router 也是用 npm 安裝。
安裝完後就是setup，他有提供一個 ui 界面，方便設定。
安裝完用：

ccr ui

就會開啟 browser，顯示設定頁面。
以 openrouter 為例，就選新增 provider - openrouter，然後到openrouter 選一些 (free) 或是 $0/M token 的 model。
在 model 的 democode 中會有 model 的名子。
舉例來說：

z-ai/glm-4.5-air:free

他的code 就有：

model="z-ai/glm-4.5-air:free"

就是他的model name，填入 provider的 add model.
一個 provider 可以add 一堆 model.

oprouter 需要一個 api_key，所以去settings--API keys 產生一個 key，把 key copy 到剛剛 claude code router 的 UI 的 openrouter 項目。
UI 設定好像這樣就可以了。
之後 'save'
就會在home 之下create ./claude-code-router/config.json

然後就可以用

ccr code

啟動 claude-code
用 stats 看，可以看到 model 還是 anthropic sonnet,
所以要用 command 來改：

/model openrouter, a-ai/glm-4.5-air:free

就可以改成 openrouter 的 glm-4.5-air model

This is my config.json (API_KEY marked)

$ cat .claude-code-router/config.json 
{
  "LOG": true,
  "LOG_LEVEL": "debug",
  "CLAUDE_PATH": "",
  "HOST": "127.0.0.1",
  "PORT": 3456,
  "APIKEY": "123",
  "API_TIMEOUT_MS": "600000",
  "PROXY_URL": "",
  "transformers": [],
  "Providers": [
    {
      "name": "openrouter",
      "api_base_url": "https://openrouter.ai/api/v1/chat/completions",
      "api_key": "sk-or-v1",
      "models": [
        "nvidia/nemotron-nano-9b-v2:free",
        "openrouter/sonoma-sky-alpha",
        "deepseek/deepseek-chat-v3.1:free",
        "z-ai/glm-4.5-air:free",
        "qwen/qwen3-coder:free",
        "moonshotai/kimi-k2:free"
      ],
      "transformer": {
        "use": [
          "openrouter"
        ]
      }
    }
  ],
  "StatusLine": {
    "enabled": false,
    "currentStyle": "default",
    "default": {
      "modules": []
    },
    "powerline": {
      "modules": []
    }
  },
  "Router": {
    "default": "openrouter,openrouter/sonoma-sky-alpha",
    "background": "",
    "think": "",
    "longContext": "",
    "longContextThreshold": 60000,
    "webSearch": "",
    "image": ""
  },
  "CUSTOM_ROUTER_PATH": ""
}

有關openrouter的 model，不是所有model 都 support claude-code-router，需要support tool 的才行：

tool-calling

所以可以follow 說明，在list model 時加上 filter: tool
另外光support tool 好像也不能完全 support claude code router，像mistral 的 model，雖然 support，但是一對tool command 他不認識。

要注意的是，ccr server 啟動之後，修改 config.json 不會生效。
要restart ccr server 才會重新 load config.json

2025/9/2

mediawiki 升級

到 special page (特殊頁面) 去，然後把網址的 : 後面改 "Version" 就會出現版本頁面，例如

http://192.168.145.166:9090/index.php/Special:Version

所以知道版本是

安裝的套件有

Tag Extension 有：

gallery，imagemap，indicator，nowiki 和 pre

把原 server 的文章，user account 倒出來

mysqldump -u wikiusername -p wikipassword > wikidb.sql

把upload 的 image 倒出來

tar -zcvf wikiimage.tar.gz /path/to/mediawiki/imagepath

這個path 在 LocalSetting.php 中的變數定義

$wgUploadDirectory=/var/lib/www/mediawiki/

clone 下面的 github project.

setupmediawikiwithextension

設定新 MediaWiki 的簡單步驟

以下是設定新 MediaWiki 的簡單步驟，使用這個專案的說明。請先確認你的電腦已經安裝 Docker 和 Docker Compose。

準備工作

複製環境設定檔案：cp .env.example .env
編輯 .env 檔案，設定必要的參數：
- MW_ADMIN_PASS：管理員密碼（預設 changeme123!，請改掉！）
- MW_SITE_SERVER：網站伺服器地址（如果不是 http://localhost:9090，請修改）
- 其他設定如 MW_SITE_NAME、MW_LANG 等，可視需要調整

啟動步驟

建置並啟動容器：
```
docker compose up -d --build
```
這會自動下載並安裝 MediaWiki 1.41，包含常用擴充套件（如語意媒體wiki、視覺編輯器等）。
開啟瀏覽器，前往 http://localhost:9090 查看你的 wiki 網站。
使用管理員帳號登入：
- 帳號：Admin
- 密碼：你在 .env 中設定的 MW_ADMIN_PASS

從現有的 MediaWiki 恢復資料

如果你有一個現有的 MediaWiki 網站，想要將其資料庫和圖片檔案恢復到這個 Docker 環境中，可以按照以下步驟操作：

1. 匯出現有資料

匯出資料庫：

mysqldump -u [使用者名稱] -p[密碼] [資料庫名稱] > wikidb.sql

打包圖片檔案：

cd /path/to/old/mediawiki
tar -czf images.tar.gz images/

或者使用 zip：

zip -r images.zip images/

2. 放置檔案

將匯出的 wikidb.sql 檔案放到此專案的 ./data 資料夾中
將打包的圖片檔案（images.tar.gz 或 images.zip）也放到 ./data 資料夾中

3. 設定環境變數

編輯 .env 檔案，新增或修改以下設定：

MW_RESTORE_ON_INIT=1
MW_RESTORE_DB_DUMP=/data/wikidb.sql
MW_RESTORE_UPLOADS_ARCHIVE=/data/images.zip

如果資料庫已經有資料表且需要覆蓋，請額外添加：

MW_FORCE_DB_RESTORE=1

4. 啟動容器

docker compose up -d --build

容器啟動時會自動執行恢復程序，將資料庫和圖片檔案匯入到新的環境中。

注意事項

第一次啟動時，系統會自動安裝 MediaWiki，即使有舊的 LocalSettings.php 但資料庫是空的，也會重新安裝並啟用擴充套件。
如果需要語意媒體wiki（SMW）的設定，請在登入後檢查並執行維護指令（參見 README 的 Maintenance 部分）。
所有資料（資料庫、圖片上傳）會儲存在 Docker 磁碟區中，網站設定檔案會存放在 ./data/LocalSettings.php。
如果圖片檔案是使用非 UTF-8 編碼（如繁體中文的 cp950），請在 .env 中設定：MW_ZIP_ENCODING=cp950

如果遇到問題，請檢查 Docker 記錄：docker compose logs -f mediawiki。

version 1.44

恭喜！

您已經成功安裝MediaWiki。
安裝程式已自動產生LocalSettings.php檔案，該檔案中包含了您所有的設定項目。
您需要下載該檔案，並將其放置在您 wiki 的根目錄（index.php 所在的目錄）中，下載應已自動開始。

2025/8/21

codex-cli

codex 安裝就跟 claude-code, gemini-cli 依樣，用 npm

npmm i -g @openai/codex

authentication 依樣會開browser，但是在 headless server (console only)就不能用以前gemini-cli 的方法。
codex提供更簡單的方法:

Headless Machine Setup

就是把 auth 過的機器上的 ~/.codex/auth.json copy 到要 auth 的機器上就可以了。

和 claude-code 的比較：

codex-cli 有明顯的"thinking"時間，以default model: gpt5-medium 來說，隨便一個簡單小命令都會花 30sec以上的thinking 時間，改用gpt-5 low 也要10sec以上，claude-code大部分回應都很快，幾乎是立即，少數會等待5,6 sec。
utility script: 以產生某工作的 script 來看（舉例來說：生成一個在 ubuntu 24.04 server 安裝 docker service 和 nvidia-container-toolkit)，claude-code 的 script 比較接近真人寫的，比較容易了解，codex-cli 的 script 比較複雜，比較難了解。雖然script 達成的結果一樣
解決問題/bug時，claude-code解決bug後會自動全面展開，找還有沒有類似的bug沒修正，codex-cli 則是遇到一個改一個。
claude-code 有搜尋網路的能力，需要的時候，claude-code 會自動搜尋需要的api 文件，codex-cli 不行，他說因為安全問題，它沒有access internet 的權限，其實這是用mcp agent來達成，不是權限問題。
對於Android 系統和 application 的知識，還是 gemini-cli 最高，codex-cli 反覆debug 的問題，gemini-cli 馬上就找到問題點。

整體來看就是：claude-code 的動作和寫的code比較接近software engineer，codex-cli 則比較像 llm ，猜這是因為 prompting 的關係，codex-cli 可能還在開發中，所以 prompting, mcp agent都寒不完整
codex-cli 目前快速改版中，應該會越來越好。

codex-cli 無法搜尋的解法，就是請它給一個prompt，讓我訊問 chatgpt，之後再把reply 貼回 codex-cli
gemini-cli 也有搜尋能力，是用 mcp:websearch 作到，所以能在無網路存取能力下作到 search internet.

本來以為不會遇到的：

🖐 You've hit your usage limit. Upgrade to Pro (https://openai.com/chatgpt/pricing), 
   or wait for limits to reset (every 5h and every week.).

25/08/27

0.24.0 更新，果然增加 websearch 功能了，thinking 的內容也不輸出了。

v0.24.0

2025/7/22

$ python3 development/vndk/tools/header-checker/utils/create_reference_dumps.py -l libcrypto
....
error: external/crosvm/rutabaga_gfx/Android.bp:59:1: "rutabaga_gfx_test_src_lib" depends on undefined module "libgfxstream_backend".
Or did you mean ["libfastdeploy_host" "libtistress-defaults" "slab_test_tests_slab" "zlib_deflate_fuzzer" "zlib_fuzz_defaults" "zlib_inflate_fuzzer"]?
error: external/crosvm/rutabaga_gfx/Android.bp:13:1: "librutabaga_gfx" depends on undefined module "libgfxstream_backend".
Or did you mean ["libfastdeploy_host" "libtistress-defaults" "slab_test_tests_slab" "zlib_deflate_fuzzer" "zlib_fuzz_defaults" "zlib_inflate_fuzzer"]?
..

要加上 -product

python3 development/vndk/tools/header-checker/utils/create_reference_dumps.py -l libcrypto -product rk3576_u

2025/7/7

TP-LINK TL-WN725N, RTL8188EU , on ubuntu 24.04

是 ubuntu-24.04-preinstalled-server-arm64-orangepi-5-plus...
dmesg

[  954.209502] usb 4-1: new high-speed USB device number 4 using ehci-platform
[  954.355029] usb 4-1: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
[  954.355048] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  954.355058] usb 4-1: Product: 802.11n NIC
[  954.355067] usb 4-1: Manufacturer: Realtek
[  954.355075] usb 4-1: SerialNumber: 00E04C0001
[  954.499151] usb 4-1: RTL8188EU rev D (TSMC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[  954.499173] usb 4-1: RTL8188EU MAC: e8:94:f6:0b:34:f5
[  954.499184] usb 4-1: rtl8xxxu: Loading firmware rtlwifi/rtl8188eufw.bin
[  954.499387] usb 4-1: Firmware revision 11.1 (signature 0x88e1)
[  955.112461] rtl8xxxu 4-1:1.0 wlxe894f60b34f5: renamed from wlan0

原來 loading firmware failed，所以

apt install firmware-realtek

他說是 virtual package，選一個 armbian-firmware，install 玩重新插拔 wifi usb.dmesg 就完成了。
然後 ip link 就可以看到 wlxe894f60b34f5

然後開始

harles-chang@orangepi5-plus:~$ nmcli device wifi list
IN-USE  BSSID              SSID                 MODE   CHAN  RATE        SIGNAL>
        54:78:C9:D4:03:EE  123456789012         Infra  1     65 Mbit/s   100   >
..

然後就可以連線了:

sudo nmcli device wifi connect "ssid" password "thepassword"

訂閱：文章 (Atom)