Zombie chrome process on middle2

如果在 middle2 上面跑 python3 fb_handler.py --update --page --max 10 --cpu 1 --site 89 --between 0 應該很快就會發現有 zombie process（我測試的情況）。

要重現這個問題可以這樣做：ssh into middle2 然後執行底下的 python code（可以用 python3 開 REPL 然後 copy paste 進去）：

import os
from selenium import webdriveroptions = webdriver.ChromeOptions()
options.headless = True
options.add_argument("--disable-dev-shm-usage")
options.add_argument("--no-sandbox")
executable_path = os.getenv("CHROMEDRIVER_BIN")
driver = webdriver.Chrome(executable_path=executable_path, options=options)
driver.quit()

結束後按 ^D 跳出 python，用 ps 查看 process list 應該就會看到 defunct chrome process（還有 cat）。我對 selenium 不太熟，但就我所知上面的 code 應該是正確的關閉邏輯 :thinking_face: 上面的 code 在 macOS 上跑是沒有問題。同樣的 code 在 changhua 和 tainan 都會產生 zombie process。

（用上面的方法測試完以後記得通知 middle2 admin 把 ssh 進去的 node release 掉。）

大概看了一下，目前看到兩個可能的原因：

chromedriver 的問題。有一說是不要加 --no-sandbox 試試看，但是我們要用 headless 好像沒有簡單的方法可以拿掉 --no-sandbox 選項
Docker 的問題。有一個 n 年前的說法是 Docker 要加 --init 它的 PID 1 才會正確地 reap zombie。這個我也不確定現今的情況是怎麼樣

另外我也不確定：tainan 應該也有一樣的問題，只是 tainan 用的 selenium process 相對少很多所以不容易發現，但為什麼 tainan 的 cronjob node 都能自動被 release 而 changhua 的不會？因為，如果 cronjob node 可以跑完就自動被釋放，那我們讓每次 update 的工作少跑一點就可以了。

一個 work around 的方法是減少新開的 chrome process。

disinfoRG / FbScraper

Zombie chrome process on middle2 #21