Slack archive

middle2

Month: 2020-03

2020-03-02

pm5 11:20:52
@ronnywang 剛才 tainan-sun-500796 11:14 的一個 cronjob 遇到了 "sh: 1: python3: not found"。我看了一下，那個 repo 上次更新是 2/29，應該是 middle2 cronjob 的問題？
這問題我發現在 1/4 開始就會有 2% 左右的 cron 會跑錯容器（因為跑錯容器所以指令失敗），我現在不太確定哪裡有 race condition 造成的 QQ ，我把程式調整了一下再觀察看看
ronnywang 11:32:21
我看看喔
ronnywang 11:34:50
咦，好像有 bug ，那邊應該是別的專案才對，我研究看看
😮 1
yellowsoar 20:34:23
說到 bug … disfactory 用了一個 ORM 的 queue 工具來處理 post method 的 request，處理的時候會把 request 的 image binary 存到 pssql 裡面(這個正在重構當中)，可是 2/23 CPU 飆高之後一直到 2/26 都沒辦法正常存取，2/26 透過 ssh tunnel 可以存取 sql (web admin 因為版本太舊無法直接顯示 sql)，當時處置是先把 queue list 刪除掉，然後透過 git push -f 和修改 middle2 env 強迫 container 重啟，但兩種方式重啟之後在 queue list 裡面都出現了 2/23-2/26 之間沒出現過的的 queue job，而且這些 job 確定是 2/23-2/26 之間 post 的測試用 request，但當時沒有收到 response。
@ronnywang @cph
不太懂意思，是指說 disfactory 會把 http request queue 起來嗎？
是 queue 在 db 裡面？
yellowsoar 2020-03-02 23:27:49
對，但只有上傳圖片的 request 會 queue 起來，然後由 middle2 上傳到 imgur
yellowsoar 2020-03-02 23:28:34
這狀態神奇到我花了幾天想清楚到底發生了什麼事….
yellowsoar 2020-03-02 23:51:38
還是說禮拜三 vtaiwan & disfactory 遠端同步來重現一下？
yellowsoar 2020-03-04 21:16:01
@ronnywang 我們測試了之後…一切又恢復正常了…
賀(？)
yellowsoar 2020-03-04 21:50:06
但是同樣程式碼的開發環境掛了＝＝

2020-03-04

2020-03-09

wenyi 21:19:03
@ayw255 has joined the channel
wenyi 21:51:16
@ronnywang 想問一下middle2有沒有什麼方法可以不用一直ssh進去也可以讓程式跑，像tmux 或 nohup 的functionality。例如現在0archive要完整抓ptt需要四五天以上，目前是讓電腦一直開著保持ssh連線才不會斷掉
yellowsoar 2020-03-10 13:07:30
技術上 ssh over http 應該辦得到？但 PaaS 還真的不是設計來這樣用的＠＠

2020-03-10

ronnywang 12:04:53
middle2 在設計上是 PaaS ，這樣的需求有點脫離 PaaS 的範圍了，原先設計 ssh 進去主要是方便了解環境 debug 用，進來裡面常態執行程式不太算是原先設計的用法了 XD
ronnywang 12:06:21
如果要 workaround 的話，繼續這樣使用的話，我覺得可能比較理想的作法是 middle2 還是不改任何東西，但是再找一台跳板主機專門負責 ssh + tmux
摁好，瞭解了！那我先找其他平台跑好了！不增加middle2的負擔

2020-03-11

2020-03-17

pm5 12:25:14
disinfo mysql 有一個 alter table 看來佔用太多記憶體了。我來把它砍掉⋯⋯

2020-03-19

ronnywang 14:00:42
@pm5 我看到你好像有在用 worker 功能了？目前我 worker 的設計是每一分鐘他會檢查該程式是否有在跑，如果發現沒在跑就會重跑
pm5 14:04:45
試用了一下，但那是只要跑一次的程式，我又不確定它什麼時候會被跑完，所以就換別的方法了

2020-03-23

pm5 10:30:50
@ronnywang 我觀察到一個容易出現 "Error: No such container: c-2" 錯誤訊息的 cronjob 情況，是 job 特別短的時候，例如在 ~3 secs 以內結束的話。最近 0archive 的 update job 有點 process management 的問題，程式執行以後，以為有另一個 process 還沒結束，所以程式就不執行工作馬上結束。這種情況下多次以後似乎蠻容易遇到 No such container。之前 @fockerlee 常遇到這個問題的 container，有些也是執行一個 ls 指令就結束的 cronjob。
ronnywang 10:32:04
問一下，有沒有可能有個情況，就是執行的 script 他會在背景執行，所以一執行指令就被我判定為跑完（但其實是在背景跑）
pm5 10:32:10
就容易發生 race condition 的狀況？也許我可以在 cronjob 加個 sleep 10 延長它結束的時間才暫時避免這個問題
ronnywang 10:32:15
結果就是緊接著 middle2 想把跑完的資源釋放掉
ronnywang 10:32:50
有 fork 但是沒有 wait 的情況
pm5 10:34:22
早上回報的那個 `ns update` 的指令是不會在背景執行的，它用的 twisted 的平行處理是跟 nodejs 一樣的 event loop 模式，所以沒有 fork。之前 fb scaper 倒是可能有這種情況
pm5 10:35:13
嗯⋯⋯也許是有。selenium 是 fork 的樣子。
pm5 10:36:38
它們都有用 selenium。selenium quit 在 docker 環境裡之前測試會遇到沒有 wait（留下 zombie process）的情況
ronnywang 10:37:50
我看記錄 no container 是發生在 shutdown 不是發生在執行時，執行可能是有順利執行完的
ronnywang 10:38:11
我這邊增加 shutdown 前 sleep (2) 試試看好了
🖖 1
ronnywang 10:39:04
確實有可能像你說的，當執行太短時，docker exec xxx ===(秒殺) ===> docker shutdown (docker 噴 No such container )
pm5 10:39:31
但 update 如果只跑了 <1s 那就是它以為有其它 process 在跑，所以馬上結束。這個情況下不會啟動 selenium，所以沒有上面講的沒有 wait 的問題。看起來還是秒殺的問題比較有可能。
ronnywang 22:36:48
在找這問題過程有發現 middle2 一個 cron 的 race condition bug (race condition 超難 debug orz)
大概情況如下：
有兩隻不同的 script
一隻是每分鐘運作一次，他會檢查有沒有哪個 wait node 超過 60 分鐘沒人用把他 free 掉，或是發現有 node 程式碼已經更新，就會標為 over 之後把他釋放掉，不讓他再被使用
另一隻是負責處理 CronJob 的，當某隻 cron 需要被跑時，他會找一個 狀態是 wait 的 node 來執行（而且程式碼要是最新的）

不過可能是因為 cache 的關係， cronjob 那邊沒發現 node 的程式已經更新了，所以拿了過時的 node 來執行 cronjob, 造成該被 free 掉的 node 因為持續有在跑東西結果一直沒被 free ，而且有時會剛好同時做 shutdown 跟執行 cronjob 造成可能的 No Container 的情況