SynologyのNASで、/dev/md0の使用率が100％になった時の対応
起きた問題
ある日、SynologyのNASにWebからログインするとエラーを吐くようになった。
日: DSMが正常に開始できませんでした。サポートに問い合わせてください。(うろ覚えの記述)
英: DSM cannot start up normally because it ran into a problem. Please contact the Synology support team for help.
日本語ははっきりと覚えてないが、上記のような内容だった。それを元に英語で検索したら同じエラーメッセージに遭遇した人がいたので、一応英文メッセージも記載。
そして、忘れたころに再び同じ問題に遭遇しそうなので、備忘録がてら解決までの流れを記載しておく。
解決までの流れ
1. 検索
わざわざエラー解決のためにサポートに問い合わせて、あれこれするのも面倒だし、似たような事例で自分で解決できればそれに越したことないと思って調べると、NASのメインのディスクに空き容量がない時に出るメッセージらしきことを突き止める。自力で解決できてる人もいたので、自分もそうすることにした。
以下、検索にかかって参考にしたページ
- https://qiita.com/nakamurahiro/items/94dd601b97e78f87cb62
- https://www.reddit.com/r/synology/comments/i8gpbe/help_nas_acting_up_devmd0_full/
2. sshでログイン
$ ssh -l aryzae 192.168.0.21
本来であれば、rootで入るところなのだが、自分の環境では、rootとなるadminのアカウントを無効化していたため、rootで入れない。
代わりに、rootと同等の権限を持つ自分のアカウントでログインをした。
3. md0の容量確認
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.3G 0 100% /
none 7.8G 0 7.8G 0% /dev
/tmp 7.8G 2.4M 7.8G 1% /tmp
/run 7.8G 9.5M 7.8G 1% /run
/dev/shm 7.8G 4.0K 7.8G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/mapper/cachedev_0 27T 14T 14T 50% /volume1
...
Filesystemの容量を調べてみると、検索にかかったページと同様/dev/md0の容量が100%になっており、空きがない。
何か不要なものを消して、100%を解消出来れば根本解決でないものの、現状の問題は回避できるのでそうすることにした。
4. ディレクトリ単位で容量確認
$ du -hd 1 --exclude=volume1
4.0K ./root
4.0K ./mnt
40K ./.old_patch_info
4.0K ./lost+found
0 ./sys
4.0K ./dev
0 ./proc
23M ./.syno
988K ./tmp
6.5M ./var.defaults
1.3G ./var
926M ./usr
4.0K ./tmpRoot
4.0K ./initrd
8.9M ./etc.defaults
9.1M ./run
84K ./.log.junior
20K ./.system_info
9.9M ./etc
0 ./config
2.3G .
sudoコマンドで叩いてないからか、途中Permission deniedが大量に出たが省略している。
./varが1.3Gあるので、ここにでかくて不要なものがあれば、それを消すことにしたので、ディレクトリを掘りつつdu -hd 1 --exclude=volume1を叩いて消せそうなディレクトリを探していった。
5. 消しても問題なさそうな容量大きいファイルの探索
$ cd var/
$ du -hd 1 --exclude=volume1
4.0K ./crash
4.0K ./synobackup
4.0K ./state
10M ./lib
4.0K ./target
7.5M ./cache
84K ./tmp
2.7M ./packages
20K ./update
8.0K ./services
1.3G ./log
2.5M ./dynlib
4.0K ./db
4.0K ./empty
28K ./spool
1.3G .
$ cd log/
$ du -hd 1 --exclude=volume1
4.0K ./selfcheck
2.0M ./healthtest
4.0K ./synolog
8.0K ./fsck
4.0K ./pstore
12M ./disk-latency
72K ./packages
4.0K ./sssd
4.0K ./nginx
332K ./samba
4.0K ./openvswitch
136K ./diskprediction
40K ./webdav
1.3G ./upstart
4.0K ./httpd
88K ./smart_result
1.3G .
$ cd upstart/
$ ls -la
total 1312024
drwxr-xr-x 2 root root 4096 May 21 12:27 .
drwxr-xr-x 18 root root 4096 May 10 10:02 ..
-rw-r----- 1 root root 450 May 5 21:13 3rdparty-services.log
...
-rw-r----- 1 root root 116 May 5 21:13 syno_pstore_collect.log
-rw-r----- 1 root root 1285435541 May 5 21:18 synoscgi.log
-rw-r----- 1 root root 54407168 May 21 12:27 synoscgi.log.1
-rw-r----- 1 root root 718888 May 21 12:27 synoscgi.log.2.xz
-rw-r----- 1 root root 719456 May 21 12:26 synoscgi.log.3.xz
-rw-r----- 1 root root 720296 May 21 12:26 synoscgi.log.4.xz
-rw-r----- 1 root root 681276 May 21 12:25 synoscgi.log.5.xz
-rw-r----- 1 root root 498 May 5 21:12 synoscheduler.log
...
-rw-r----- 1 root root 0 May 5 21:11 WDidle3Dis.log
環境にもよるだろうが、自分の環境においては、/var/log/が容量食っていた。
logであれば、消してもまず問題なさそうだと思ったので、logの中でさらに1番大きい容量のファイルを探した結果、synoscgi.logが1.3G近くあった。ついでにいえば、synoscgi.log.*のほかファイルも結構な容量があったので、まとめて消してしまうことにした。
6. ファイルの削除
$ sudo rm -f synoscgi.*
もしかしたらchmodコマンドも必要かもしれないが、rmコマンド叩いてファイルの削除を行なった。
$cd /
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.3G 0 100% /
none 7.8G 0 7.8G 0% /dev
/tmp 7.8G 2.4M 7.8G 1% /tmp
/run 7.8G 9.5M 7.8G 1% /run
/dev/shm 7.8G 4.0K 7.8G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/mapper/cachedev_0 27T 14T 14T 50% /volume1
...
注意しなければいけないのが、ファイルを削除してrootに戻り、容量を確認しても/dev/md0の容量は即座に変化しないとこだ。
7. NASの再起動
NAS自体を再起動しないと容量の状態は反映されないようである。
なので、再起動した。
再起動後に、エラー？ワーニング？が表示されなく、動作も問題なかった。
余談
NASにsshで入ってファイル削除するのは知識ない人からするとハードルが高く、イレギュラーなやり方ではある。
真っ当なやり方は、サポートに連絡して解決することだが、調べた限りだとサポートに連絡した際、遠隔で自分のNASを操作してもらうことになり、そのためにID/PASSを伝えなければいけないとあった。さすがにID/PASSを教えて操作してもらうのは心理的にもリテラシー的にも無理あった。気にならない人ならサポート経由で処理するのもありだろう。
もう1つ真っ当ぽいやり方が、DSMの初期化である。NASに置いているファイルはそのままで、OSとして動いているDSM自体を初期化することで、肥大した/dev/md0もクリーンな状態に戻せるらしいことが検索してる時にわかった。
ただ、初期化したらアカウントやマウント周りの設定等を1から構築するのは厳しい。そのためにバックアップを取る必要があり、Hyper BackupをNASにインストールしてバックアップ取る必要がある様子。/dev/md0が100％だと結局Hyper Backupインストールすることも出来ないので、事前にインストールしててバックアップ取ってる人しか出来ない方法ではある。
次からはDSM初期化してから復元できるように、/dev/md0の100%が解消したらHyper Backupをインストールして、設定周りをバックアップ取っておくのが良さそうである。
Discussion