常見錯誤對照¶

依症狀分類。先在這張表找，找不到再去 log 位置與分析。

啟動類¶

`tapioctl start` 失敗，pidfile 未出現¶

原因：binary 啟動瞬間就死亡（segfault / 缺 lib / config 錯）。

解法：

# 看 stdout（binary 死前最後輸出）
tail -50 /opt/Tapio/log/$(readlink /opt/Tapio/storage/current)/stdout/tapio-core.log

# 用 ldd 看缺 library
ldd /opt/Tapio/bin/tapio-core | grep "not found"

# 直接 run 看更詳細的錯
/opt/Tapio/bin/tapio-core

`tapioctl start` 報 `已在執行`¶

原因：pidfile 存在 + 對應 process 仍活著。

解法：

tapioctl status   # 確認確實在跑
# 真的要重啟用：
tapioctl restart

`tapioctl start` 報 `pidfile stale，啟動失敗`¶

原因：pidfile 寫入失敗或 setsid 機制壞了。

解法：

ls -la /opt/Tapio/run/
# 看 pidfile owner 是否對（operator user）
sudo chown -R <operator>:<operator> /opt/Tapio/run
rm -f /opt/Tapio/run/tapio-core.pid
tapioctl start

巡檢類¶

`tapioctl check tcpdirect` 報 `libonload_zf.so 是 debug build`¶

原因：TCPDirect stock tarball 預設裝 debug build。

解法：重 build release 版本的 TCPDirect（參考 Solarflare 官方文件）。

`tapioctl check pfiles` 報缺檔¶

原因：產品檔下載未完成或失敗。

解法：

查 tapio-taifex-fetcher log，確認失敗原因（網路、認證、SFTP 伺服器端錯誤）
重新觸發抓檔：

tapioctl restart taifex-fetcher

若仍抓不到，清掉當天資料夾內容後再重啟：

rm -rf /opt/Tapio/data/taifex/<YYYYMMDD>/*
tapioctl restart taifex-fetcher

取得期交所檔案的來源依手上有無 SFTP 帳密分流：
有 SFTP 帳密 → 直接走 SFTP 流程重抓（上方 fetcher 即用此帳密連線）
無 SFTP 帳密 → 向交結後台詢問索取
若緊急來不及：cp /opt/Tapio/data/taifex.bak/* /opt/Tapio/data/taifex/ — 僅限緊急，新合約上架日可能跑錯

`tapioctl check disk` 警告¶

解法：

# 看哪個目錄最大
du -sh /opt/Tapio/log/* | sort -h | tail
du -sh /opt/Tapio/storage/* | sort -h | tail

# 清舊 log（保留 30 天）
sudo find /opt/Tapio/log -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +

storage/ 內的 daily 不要隨便刪（reconciliation / audit 用）— 先 tar.gz 移到 NAS 再刪。

行情類¶

tapio-quote-receiver 啟動但 tapio-core 拿不到行情¶

原因（依機率排序）：

shm ring 被昨天殘留檔污染
multicast IP 設錯（tapio-quote-receiver 跟 broker 約定的 IP 不同）
NIC 沒收到多播（switch IGMP / firewall）

解法：

# 1. 清 shm ring
tapioctl stop quote-receiver
tapioctl quote-clean
tapioctl start quote-receiver

# 2. 看 multicast IP 對不對（build time 烤入，參考對應部署）
sudo -u <operator> /opt/Tapio/bin/tapio-quote-receiver --help
ps aux | grep tapio-quote-receiver

# 3. 看 NIC 是否收到 multicast
sudo tcpdump -i ens1f0 -nn 'udp and dst <multicast-ip>' -c 10

quote-receiver 收不到 multicast、stdout log 停在啟動訊息¶

症狀：quote-receiver 正常啟動（stdout log 有 priceLimit seqlocks clean on startup 等開機訊息），之後完全不再寫 log — 沒有 heartbeat、沒有 symbol(...)。在行情 NIC 上 tcpdump 抓得到 multicast 封包，但 quote-receiver 收不到。

原因：multi-homed 主機的 reverse-path filter（rp_filter）。行情 multicast 從某張 NIC（例：ens1f0np0）進來，但 feed source 子網的反向路由走另一張 NIC（例：eno8303）。收包 NIC 的 rp_filter 為 strict（1）時，kernel 在 IP routing 層就把每個行情封包丟掉 —— 發生在送進 socket 之前、也在防火牆判斷之前，所以 quote-receiver 完全無感，UdpInErrors 也不會動。

診斷：

# 1. 封包有到 NIC 嗎（抓得到 = 不是 switch / feed 問題，往下查）
sudo tcpdump -ni <行情NIC> 'udp and dst net 225.0.0.0/8' -c 10

# 2. 收包 NIC 的 rp_filter（effective = max(all, <iface>)）
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.<行情NIC>.rp_filter

# 3. 關鍵：feed source 的反向路由走哪張卡？（source IP 從步驟 1 的 tcpdump 取）
ip route get <feed-source-IP>
#   顯示的 dev 不是行情 NIC ⇒ strict rp_filter 會丟掉所有行情封包

解法：把行情 NIC 的 rp_filter 改為 loose（2）。loose 仍擋真正路由不到的偽造來源，足以修好且比全關（0）安全。

# 立即生效
sudo sysctl -w net.ipv4.conf.<行情NIC>.rp_filter=2

# 持久化（否則重開機打回 strict）
echo 'net.ipv4.conf.<行情NIC>.rp_filter = 2' | sudo tee /etc/sysctl.d/90-quote-mcast.conf
sudo sysctl --system

interface-specific sysctl 於開機時需該 NIC 已存在才會套用；重開機後務必 sysctl net.ipv4.conf.<行情NIC>.rp_filter 複查一次是否仍為 2。

升級後類¶

升級後 capabilities 不見了¶

原因：post_install 沒重設 setcap。

解法：

sudo setcap cap_ipc_lock,cap_net_admin+ep /opt/Tapio/bin/tapio-core
getcap /opt/Tapio/bin/tapio-core

升級後效能退步¶

檢查： 1. tapioctl check tcpdirect — 是否退到 debug build / 缺 kmod 2. NIC firmware variant 還在 ultra-low-latency 嗎？sudo sfboot --adapter=ens1f0 3. tuned profile 還是 network-latency 嗎？tuned-adm active 4. /proc/cmdline 仍有 isolcpus=...?

任一漂移都會大幅退化。

排程類¶

cron 排程到了 tapioctl 沒跑¶

sudo journalctl -u crond -n 100 | grep tapio

常見： - operator user 不存在 (useradd <operator> 沒做) - PATH 少了某個 binary（cron PATH 預設極小，用絕對路徑） - crontab 語法錯（漏 * 或 user 欄位）

tapioctl 跑了但拿不到結果（cron 環境）¶

→ 模擬 cron 環境手動跑：

sudo -u <operator> bash -c 'env -i PATH=/usr/bin:/bin /opt/Tapio/bin/tapioctl start'

若這樣會錯、登入 shell 不會錯，就是環境變數差異問題。