『/ ファイルシステムフルで管理画面反応しなくなって来ました』のクチコミ掲示板

[KplusPlus]

2021年7月の最新ファーム(4.5.4.1741)の一つ前あたりのファームに更新したあたりから、管理画面にファイルシステムフル(/)の警告が出るようになり、いつの間にか管理画面にもアクセスできなくなりました。利用者側環境はいじっておらず変更点はなし。
ファームを疑い、サポートチケット発行して対応してもらいました。
切り分けで最新ファームファイルを改めて適用したが、ブートプロセスの表示がブート中のまま、でも実はNASとしては稼働している状態に陥りました。
フロントパネルから操作もできないので、強制的に電源OFF-ON。その後も/ファイルシステムフル発生。いずれは管理画面にもアクセスできなくなる予想。
サポートでは、ターミナルで状況を見させてくれというので、TeamViewerで画面共有して、ファイルシステム見てくれました。
以前、似たようなバグがあったそうですが、ファームが最新でなおっているはずなので技術者チームに連携して確認してくれるようです。
早く問題解決することを願うばかりです。メインで使っていなくてよかった。

ここからは単なる私見
仕事柄、台湾のソフトウェア開発チームとやりとりしますが、開発しているのは大陸。というパターンが多いです。QNAPはどうなんでしょう。
日本でも、大手SIerの先は中小、またその先は大陸。よくあります。コミュニケーションの問題も発生しやすい。
面倒なバグで長らく苦しんでいると、結局はOS(今回はLinux)のバグだったというあるある話もありますし、ちょっとしたところを手直しするサイレントチェンジしたところで躓くのはよくあることなので、気長に待つことにします。

書込番号：24282612

[ZUUL]

経過を読んでみると、ソフトウェア製品が未完成のまま
売られていて、なので、サポートが必要、という典型のようです。

RMAプロセスを訴求するのは、検査が半端なものを出荷しているからでしょう。

書込番号：24282727

[LsLover]

『いつの間にか管理画面にもアクセスできなくなりました。』

という状態ですと、

『管理画面にファイルシステムフル(/)の警告が出るようになり、』

エラーメッセージを画面キャプチャーでアップロードできませんか?

「ファイルシステムフル(/)」ということですと、内蔵HDDの空きエリアが無い状態のようですが...。

『フロントパネルから操作もできないので、強制的に電源OFF-ON。その後も/ファイルシステムフル発生。いずれは管理画面にもアクセスできなくなる予想。』

「強制的に電源OFF-ON」してしまうとファイルシステムの破壊などにより、起動不可となる可能性もあるかと思います。
「ファイルシステムをチェック」で自動修復できれば良いのですが、状況によっては自動修復できず、マウントもできない状態も予想されます。

『
NAS システムログに [File system is not clean ( ファイルシステムが乱れています)] と表示されるのはなぜですか？
「ファイルシステムに問題があります」というメッセージは、データを含んでいるボリュームが正しくアンマウントされなかった場合に表示されます。これは次のような状況で起こります。
』
https://www.qnap.com/ja-jp/how-to/faq/article/nas-%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%AD%E3%82%B0%E3%81%AB-file-system-is-not-clean-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%8C%E4%B9%B1%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99-%E3%81%A8%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%A7%E3%81%99%E3%81%8B

書込番号：24283518

[KplusPlus]

管理画面では簡易にファイルシステムフルの旨が表示されるだけです

＞ZUULさん ＞LsLoverさん
私のためにお時間を割いていただきありがとうございます。感謝いたします。

＞ZUULさん
私見ですが、ファームウェアの更新回数がNETGEARのそれと比にならない位多いですね。
機能数が違いますので簡単に比較することはできませんが、ユーザからの故障申請に対応して品質を上げていく手法、"シフトライト"なのかも知れません。いや、リリース後ですから、シフトライトのさらに右ですね。　あっ、人柱かも(苦笑)。　にしては結構なお値段。
シフトレフトの方が、みんなが幸せになれるのですが、拙速を旨とする競争の世界では致し方のないことかも知れません。
あと、ひょっとするとエラー発生時のリカバリ実装がそれほどでも無いのかも知れません。

＞LsLoverさん
fsckのおすすめ、ありがとうございます。早速実行し、無事完了しました。
管理画面に出でくるファイルシステムフルの表示は簡易なもので起きたこと最小限のことを伝えています。
裏で、FULL.logとしてdf,duの出力結果が格納されていました。(最下部に貼ります。文字数の関係で抜粋です)
/var/log/qulog/mariadb.err のサイズが大きいです。
事象発生以前の何らかのオペレーションをきっかけに、リカバリ実装のないところで不具合が生じたのかも知れません。

qfullなるアプリを入れて、リモートセッション有効にして待ち状態です。

----ここからFULL.log抜粋-----
=== df output ===
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 0 100% /
devtmpfs 3.8G 12.0K 3.8G 0% /dev
tmpfs 64.0M 2.8M 61.2M 4% /tmp
tmpfs 3.8G 188.0K 3.8G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
/dev/mmcblk1p5 7.7M 46.0K 7.7M 1% /mnt/boot_config
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 57.4M 436.1M 12% /mnt/HDA_ROOT
cgroup_root 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
14.1T 5.7T 8.5T 40% /share/CACHEDEV1_DATA
/dev/md13 417.0M 390.3M 26.7M 94% /mnt/ext
tmpfs 1.0M 0 1.0M 0% /share/external/.nd
tmpfs 1.0M 0 1.0M 0% /share/external/.cm
tmpfs 1.0M 0 1.0M 0% /mnt/hm/temp_mount
tmpfs 48.0M 88.0K 47.9M 0% /share/CACHEDEV1_DATA/.samba/lock/msg.lock
tmpfs 16.0M 0 16.0M 0% /mnt/ext/opt/samba/private/msg.sock
tmpfs 8.0M 0 8.0M 0% /var/syslog_maildir
tmpfs 16.0M 0 16.0M 0% /share/NFSv=4
/dev/mapper/cachedev1
14.1T 5.7T 8.5T 40% /share/NFSv=4/Public
hdsfusemnt 16.0M 0 16.0M 0% /share/CACHEDEV1_DATA/.qpkg/HD_Station/share
/dev/mapper/vg1-lv1312
1.8G 1.1M 1.8G 0% /mnt/pool1
/dev/mapper/vg1-snap10003
14.1T 5.3T 8.8T 37% /mnt/snapshot/1/10003
tmpfs 512.0M 115.7M 396.3M 23% /mnt/.fw_update_dir
/dev/mmcblk1p2 216.9M 206.0M 11.0M 95% /root/FLASH_RFS1
/dev/mmcblk1p3 216.9M 206.0M 11.0M 95% /root/FLASH_RFS2
/dev/mmcblk1p6 3.9M 39.0K 3.8M 1% /tmp/nasconfig_tmp

=== du output ===
6.8M /usr/local/bin
--省略--
104M /var/log/qulog/mariadb.err
104M /var/log/qulog
107M /var/log
--省略--
108M /var
4.4M /bin
401M /
----ここまでFULL.log抜粋-----

書込番号：24283840

[LsLover]

『----ここからFULL.log抜粋-----
　=== df output ===
　Filesystem Size Used Available Use% Mounted on
　none 400.0M 400.0M 0 100% /』

root（/）パーティションが400MBすべてを使用している状態のようです。
以下の内容は、参考になりませんか?
ファイルシステムの設計時に何故400MBに設定したんだろう...?

『
"No space left on device" msg although there is space free #3994
I just had a very similar issue with my qnap nas.
Running a simple borg info resulted in "No space left on device".
How to fix:
Check free space with df -h
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 32.0k 100% /

After running rm -r ~/.cache/borg/

Filesystem Size Used Available Use% Mounted on
none 400.0M 207.9M 192.1M 52% /
Change cache dir to fix the problem
https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables

You should use something in /share/CACHEDEV1_DATA as your cache dir
』
https://github.com/borgbackup/borg/issues/3994

『
General
Borg consists of a number of commands. Each command accepts a number of arguments and options and interprets various environment variables. The following sections will describe each command in detail.
』
https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables

書込番号：24284006

[KplusPlus]

＞LsLoverさん
ありがとうございます。

サポートからは、開発チームにログは渡してあるので、推移を見守ってほしいと連絡がありました。
推移という意味で、4-5時間で
前　none 409600 298760 110840 73% /
今　none 409600 302508 107092 74% /
と徐々に増えていってます。うまいことログローテイトの機能(に類似のもの含めて)が働いていれば、問題はないのでしょうが、そこまで見てみる余裕が今はないのが悩ましいところです。
/を400Mとしたのは、足りると思ったのでしょうね。または、組込としての容量制限とか…
一杯にならないよう、余裕のあるパーティションに逃すのも一手ですね。
開発チームがどういう見立てをしてくるのか楽しみではあります。

書込番号：24284512

[LsLover]

『サポートからは、開発チームにログは渡してあるので、推移を見守ってほしいと連絡がありました。
　推移という意味で、4-5時間で
　前　none 409600 298760 110840 73% /
　今　none 409600 302508 107092 74% /
　と徐々に増えていってます。』

具体的にどのディレクトリのデータがroot partition（/）を圧迫しているのか不明ですが、前73%->今74%と使用率が増えていることが気がかりです。

書込番号：24284631

[KplusPlus]

＞LsLoverさん
ありがとうございます

ルートパーティションだと、どのファイルが増えているか、マウントテーブルで対象外除外しつつ探すと地味に時間がかかりますね。
ざっと見てみたところでは、
　/var/log/qulog/mariadb.err
　/var/log/qulog/qulogd.log
が地味なサイズながら着実に増えていってます。qulogd.logはログローテイトしていますね。
crontab見てみます。久しぶりなので、思い出すのに時間がかかりそうです。
他にもサイズ増えているファイルありそうな気がします。
mariadb.errは
　YYMMDD hh:mm:ss [ERROR] qulogdb: Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed
qulogd.logは
　YYYY-MM-DD hh:mm:ss,msec [Warning] [Database] mysql errno(144) Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed: mysql_stmt_execute
数十秒間隔で出ています。データベーステーブル壊れているみたいですね。壊れ方にもよりますがリペアするだけで済みそうな気が…
QNAPサポート、このログまで収集していったはずなので、次のアクション指定がどうなるか、期待しつつ待つことにします。
(設定バックアップして、シャットダウン。HDD外して再起動してリセット、その後は復旧手順　といったところでしょうか。)
QNAP NAS Community Forumにも似た投稿があるようです。
サポートとのやり取りですが、何故か英語で始まってしまったので、ずっと英語で時々google先生のお世話になりながらやりとりしています。
最初から日本語ならば、日本語ができる人がアサインされるようですが、途中からだとバトンタッチしてくれないようです。お願いしたけど、スルーされました。人員数の関係でしょうか。日本市場のスケールでは仕方ないかも知れません。

Forum等が充実しているIT機器のサポートの場合、サポートより自身の調査の方が、結論に先に辿り着いてしまうことが少なくないと感じています。(内外問わずですが… )
かといって、個人が知りうる情報は限られていますので、サポートの解析を待とうと思っています。

書込番号：24286328

[KplusPlus]

追記
QuLog Centerが本日(つい先ほど)リリースされインストールしたところ、mariadb.errのログは出力されなくなり、qulogd.logの
YYYY-MM-DD hh:mm:ss,msec [Warning] [Database] mysql errno(144) Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed: mysql_stmt_execute
が出力され続けています。

書込番号：24287010

[KplusPlus]

一度投稿しましたが、消えていたので再投稿(申し訳ないですが、思い出すのも面倒なので一部だけ)します。

トラブル事象は無くなったとサポートから連絡がありました。
無くなったとはいっても、実際は一次対処しただけです。/dev/nullにリンクしログを捨てているだけです。
　/var/log/qulog/配下
　　前　-rw-rw---- 1 admin administrators 1184541 2021-08-12 21:37 mariadb.err
　　後　lrwxrwxrwx 1 admin administrators 9 2021-08-13 11:08 mariadb.err -> /dev/null
パーティションフルを出なくした、という意味では解消ですが… 個人的には、穴ほって埋めて隠されたといった感じです。
正常動作しない機能がないことを祈ってます。

書込番号：24290109