GitLab故障排除紀錄


作為公司碩果僅存的MIS,打開gitlab時如果看到502就會覺得噢又來了,然後一邊抱怨一邊連回伺服器處理。

呂布也救不了你

軟體業有個說法,說可以治百病的不是華佗,是呂布(reboot)
但上次gitlab掛點我卻發現關掉之後連整個docker的container都無法重新掛載起來,重開機不僅沒有治百病,反而還直接死給你看,那時候只有一個想法:我要趕快辭職潛逃了XDD

追蹤問題

公司的gitlab是用docker架的,所以如果連container都掛載不起來,那問題實在是有點惱人,但還好,我們還有log可以查。

docker logs --tail 50 --follow --timestamps YOUR_CONTAINER_NAME

吐出的log片段如下

...26Z Initializing logdir...
...28Z Initializing datadir...
...97Z Updating CA certificates...
...09Z Installing configuration templates...
...99Z SSL Key, SSL Certificate and DHParam were not found.
...18Z Assuming that the container is running behind a HTTPS enabled load balancer.
...73Z Configuring gitlab...
...25Z envsubst: write error: No space left on device

重點應該就是最後一句啦 磁碟空間用完了。

抓兇手

下指令看了一下公司伺服器的磁碟容量,雖然不大但應該夠用(因為有在運作的服務也所剩無幾),所以找出到底是哪個資料夾最占空間應該是目前的主要任務,畢竟要刪就要從最肥的開始刪才是最有效率的做法。

上網查了一下做法,最後整理出的指令如下

du -h --max-depth=1 | sort -hr

該指令會列出目前目錄下的資料夾佔用空間,並依大小排序,然後你就可以一層一層cd進去,直到找到目標位置。

最後發現的兇手位在 ./srv/docker/gitlab/gitlab/backups/ 底下。
啊這不就是gitlab自己的備份檔嗎!??

解決問題

繞了一大圈,最後得到的結論是不知道為什麼,gitlab的備份機制從某天開始,忽然不會自己把過時的備份檔刪除,所以磁碟空間後來就被塞爆了。
懶惰如我,選擇把備份紀錄刪一刪,先把gitlab開起來再說,至於為啥備份檔忽然不會自己刪除了,之後有空再來處理囉。看要不要寫個排程來刪檔案之類的。

最後附上刪除3天前的所有備份檔的指令

find ./srv/docker/gitlab/gitlab/backups/*.tar -mtime +3 -exec rm -rf {} \;
Hi 喜歡這篇文章的話 或許可以請我喝杯咖啡
Buy me a coffeeBuy me a coffee