早晨我例行的摸了一下鏈接到樹莓派的硬盤，結果發現它不轉了。Nani?
於是我立即嘗試登錄寶塔面板，結果發現卡在登錄頁面。
使用SSH重啓之後根本重連不上，網關提示根本沒給它分配IP，就是說它現在不能聯網。
我把樹莓派強制斷電後插電，可以連上了，但是提示的消息卻讓我比較震驚…
於是我決心把他弄懂。
問題初步排查
首先肯定是要確定磁盤佔用是這樣…
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 782M 60M 723M 8% /run
/dev/mmcblk0p2 117G 117G 0 100% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 152M 101M 60% /boot/firmware
/dev/sda1 916G 95G 776G 11% /media/backup
tmpfs 782M 4.0K 782M 1% /run/user/0是這樣沒錯，然後要定位到主目錄，看看到底那個文件夾出了問題。
$ cd /
$ du -h -x --max-depth=1
74M ./home
2.9G ./usr
8.0K ./.disk
24K ./snap
4.0K ./mnt
4.0K ./srv
114M ./root
72K ./tmp
117M ./boot
16K ./opt
8.0K ./patch
6.1M ./etc
4.0K ./media
4.1G ./www
110G ./var <- 問題根源
16K ./lost+found
117G .經過一番定位之後，現在可以發現問題的根源在這個文件夾裏:
/var/lib/docker/containers/6c8a****13f4/進一步定位那個文件出了問題:
$ ll
total 112907424
drwx------ 4 root root 4096 Jan 7 04:41 ./
drwx------ 4 root root 4096 Feb 3 21:06 ../
-rw-r----- 1 root root 115617058816 Feb 18 13:05 6c8a****13f4-json.log
drwx------ 2 root root 4096 Feb 3 16:33 checkpoints/
-rw------- 1 root root 3958 Jan 7 04:41 config.v2.json
-rw-r--r-- 1 root root 1513 Jan 7 04:41 hostconfig.json
-rw-r--r-- 1 root root 13 Feb 5 13:29 hostname
-rw-r--r-- 1 root root 174 Feb 5 13:29 hosts
drwx------ 3 root root 4096 Feb 3 16:33 mounts/
-rw-r--r-- 1 root root 612 Feb 5 13:29 resolv.conf
-rw-r--r-- 1 root root 71 Feb 5 13:29 resolv.conf.hash恐怖的發現…這個日誌文件竟然佔了這麼多的大小…
修復問題
看了一下日誌，整個日誌基本全是 P2P文件交換的記錄。
離譜的是這個日誌居然是以毫秒記錄的，有的地方甚至一毫秒幾十行…這個樹莓派是怎麼支撐過來的?
因爲沒有值得注意的東西，我就直接 rm 掉了。瞬間執行，滿足感還是很高的, WinServer不知道刪到猴年馬月去。
(Ext4文件系統刪除文件時並沒有對數據進行操作，我的理解中是將記錄文件信息的索引釋放掉了，在系統的想法裏這片空間又變回可寫的了)
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 782M 79M 703M 11% /run
/dev/mmcblk0p2 117G 9.3G 103G 9% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 152M 101M 60% /boot/firmware
/dev/sda1 916G 95G 776G 11% /media/backup
tmpfs 782M 4.0K 782M 1% /run/user/0很好，空間佔用回到正常了。
防止問題重複
既然知道了是日誌文件的問題，現在就要搞清楚到底那個容器出了問題。
$ docker ps -a
CONTAINER ID IMAGE
84e1a7934eb6 linuxserver/syncthing:latest
6c8a506e5aca linuxserver/resilio-sync:latest現在就知道哪裡出現問題了。可以看到，resilio-sync 的id對應了那個日誌文件的開頭。
我更改了resilio sync中的設置，分別更改爲
log_size = 0
log_ttl = 0
disk_low_priority = true希望這樣可以有效果，我會在幾天後再來查看。
实测这样子并没有效果，看起來是Docker鏡像製作時留下來的問題, 直接在容器裡更改配置不起作用.
那這不簡單.
docker pause ResilioSync
rm 6c8a****13f4-json.log
ln -s /dev/null 6c8a****13f4-json.log$ ll
總計 36K
drwx------ 2 root root 4.0K 1月 1 2038 checkpoints
-rw------- 1 root root 4.9K 5月 5 10:25 config.v2.json
lrwxrwxrwx 1 root root 9 5月 5 10:26 6c8a****13f4-json.log -> /dev/null
-rw-r--r-- 1 root root 2.2K 5月 5 10:25 hostconfig.json
-rw-r--r-- 1 root root 13 5月 4 22:14 hostname
-rw-r--r-- 1 root root 174 5月 4 22:14 hosts
drwx-----x 2 root root 4.0K 1月 1 2038 mounts
-rw-r--r-- 1 root root 61 5月 4 22:14 resolv.conf
-rw-r--r-- 1 root root 71 5月 4 22:14 resolv.conf.hashdocker unpause ResilioSync问题到此解决
沒解決.
這樣做之後確實一時爽, 但是過了一天我回來看, 發現容器停止運行, 原因是
/mnt/data/docker/containers/6c8a****13f4-json.log/dev/null no file or directory所以問題到底怎麼解決呢?
經過一番搜索(現在才想起來有谷歌這回事)之後, 我得到了結果, 問題完美解決.
原來是可以通過配置 docker-compose 來限制logsize的, 比如說我要限制 nginx 的 logsize 為5g, 我可以
nginx:
image:
restart: always
logging:
driver: “json-file”
options:
max-size: “5g” 那麼我是用portainer管理docker的, 我可以
問題到此真正完美解決.