ブート時に自動fsckを実行した後、マウントカウントがリセットされない
Xubuntu 15.10（wily）を実行しているPCがあります。システムは、パーティションが20回マウントされたときにパーティションでfsckを実行するように構成されています。その後、予想される動作は、マウントカウントをリセットすることですが、リセットしません。つまり、マウント数が20を超えて増加し続けると、PCが起動するたびにfsckが自動的に実行されます。
tune2fsは、ファイルシステムの状態がクリーンであり、smartctlに問題がないことを示しています。
これまでに使用された回避策：
- 使用する
tune2fs -Cマウントカウントを手動でリセットするには - Live CDから起動し、パーティションでfsckを実行します。これは、終了時にマウントカウントを適切にリセットするようです
次回マウントカウントが20に達すると、問題が再び表示されます。自動fsckの実行後にマウントカウントがリセットされません。
このサイトや他の場所で検索しましたが、問題の原因についてのポインタは見つかりませんでした。何か案は？
前もって感謝します。
少し調査した結果、問題はsystemdパッケージのsystemd-fsckdサービスにあることがわかりました。執筆時点で、wilyおよびxenialで使用可能なバージョンには、問題のコード（それぞれ225-1ubuntu9および229-4ubuntu4）が含まれているようです。
解決
システムの正常な動作にサービスは必要ないため、簡単な解決策は次のコマンドを実行してサービスを無効にすることです。
systemctl mask systemd-fsckd.service systemd-fsckd.socket
欠点は、プリマスがfsckの進行状況を報告しないことです。実際、ファイルシステムのチェックが進行中であることをユーザーに通知することさえしません。
説明
サービスのmanページ からの背景
systemd-fsckd.serviceは、ファイルシステムのチェックの進行状況を受信し、一部の統合データをコンソールとプリマス（実行している場合）に送信するサービスです。また、チェックのキャンセルの可能性も処理します。
systemd-fsckdは、fsckからファイルシステムチェックの進行状況に関するメッセージを受信しますUNIXドメインソケット[...]
このサービスの問題は、進行情報を得るためにソケットでepoll_waitを実行している間、30秒のハードコードされたタイムアウトを使用することです。 fsckが30秒未満で進行状況を報告しない場合、systemd-fsckdはソケットを閉じ、表示できる範囲でログを記録せずに成功して終了します。
次にfsckが（現在閉じられている）ソケットに書き込みを行って進行状況を報告するとき、SIGPIPEで死にます。 fsckが終了しないため、マウントカウントはリセットされません。