Zeroplex 生活隨筆

今天服務一直中斷，稿不清楚狀況，只是開 console 進機器看，沒看還好，看了嚇一跳，硬碟空間全部被吃光了。

所以先嘗試把可以清空的資料清空：

sudo apt-get autoclean
sudo apt-get clean

cd ~
rm -fr .cache/*

空出了一些空間，但是也大概只有 1 % 左右，所以用 du 掃了一下目錄狀況，發現 /var 佔用超過 10 GB 的空間，這樣目標很明顯了：Docker 或是 MySQL。


先看 Docker，的確不少已經中止不再使用的 container，直接清空：

 $docker system prune
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - all dangling build cache
Are you sure you want to continue? [y/N] Y

du 看了一下， /var 還底下還是有一些佔空間的檔案：



找了一下和 log 有關的設定：

max-binlog-size = 128M
innodb-log-file-size = 64M

似乎都沒與此事件無關。不過看到關鍵字「binlog」，查了一下用途，是 master / client 用來同不的 log，應該是我之前抄 DK 的設定檔，抄完忘記把不需要的東西拔乾淨的關係 XD



兇手找到了就不用客氣，把 MySQL replication 的設定全部註解掉。再來登入 MySQL，使用指定把 replication log 全部清乾淨：

purge master logs before now();

今天剛好要處理 Zip 檔，目前看到功能比較齊全的專案應該是 Ne-Lexa/php-zip，但是用 composer require 時卻發生 error message 大噴發：



仔細一看 .... 居然有「v9.99.99」的版號，該不會要世界末日了吧？


打開 comploser.lock 看一下是怎麼回事，追蹤後得知相依性如下：

laravel v6.10.1  <=  ramsey/uuid ^v3.7

ramsey/uuid  <=  paragonie/random_compat": "^1 | ^2 | 9.99.99"

兇手抓到了，看來在 paragonie/random_compat 有一個版本號是 v9.99.99，composer 會自動拉最新的版本號來使用，因此只要任何專案 require 時沒有指定版本編號，composer 就會自動把相依性對到 v9.99.99，如果其他 package 有關連到，就是直接 dependency conflict 了。


要處理掉這個問題，只要在 composer.json 也 require paragonie/random_compat，但是加上指定版本編號如 ^v2.0，這樣 composer 就只會拉到 v2.x.x 的版本，不會去用 v9.99.99 這個版本。


ref:

• Versions and constraints - Composer