サービスが動作しているようですが、期待されるファイルは空のままです。設定を変更したり、journalctlの何百行も探る前に、サービスが書き込むべきディレクトリを直接観察してください。
inotifywaitは、カーネルによって検出された作成、変更、および移動を表示します。書き込みが制限されていることを確認し、このツールがもはや十分でないときを知ることができます。
監視を開始する前にパスを特定する
絶対パスから始めます。systemdサービスは/var/log/nom-serviceに書き込むことができ、アプリケーション用ディレクトリに、またはシステムログにのみ書き込むことがあります。DebianやUbuntuでは、まずユニットとそのログを確認してください：
sudo systemctl status mon-service --no-pager
sudo journalctl -u mon-service -n 50 --no-pager具体的なファイルがすでにある場合は、その所有者、権限、および使用可能なスペースを確認してください。監視は空のディレクトリやディスクのフルを修正するものではありません。
sudo ls -ld /var/log/mon-service
sudo df -h /var/log/mon-service次に、コマンドが不足している場合はinotify-toolsをインストールします。このパッケージはDebianとUbuntuでこの名前です。
sudo apt update
sudo apt install inotify-toolsRHEL、Fedora、またはRockyのマシンでは、パッケージも一般的にinotify-toolsと呼ばれます。インストールの前に、設定されているリポジトリでその名前を確認してください。
制限されたディレクトリ内の書き込みを監視する
専用のセッションを開き、1つのディレクトリを監視します。このコマンドはCtrl+Cが押されるまでフォアグラウンドに残ります。
sudo inotifywait -m -e create,modify,move,delete /var/log/mon-serviceオプション-mは監視をオープンのままにします。要求されたイベントは、単純なファイルの参照を表示しないようにします。その後、サービスを書き込むはずのアクション（例えば、テストリクエストや既に予定されている再起動）をトリガーします。
例えば、CREATE application.logやMODIFY application.logという結果は、カーネルがこのフォルダ内での操作を確認したことを示します。まだ内容が正しいかどうかはわかりません。それでは、そのファイルの最後の行を読みます：
sudo tail -n 30 /var/log/mon-service/application.logガイドtailでログを追跡するは、イベント後に内容を再度読み取るために役立ちます。サービスがsystemdにのみ書き込む場合は、journalctl -u mon-service -fを使用してください。
サービスに触れずに試す
本番アプリケーションを観察する前に、ラボ用のフォルダーを取ります。これにより、アクティブなサービスのイベントと混同することなく、構文と権限を確認できます。
mkdir -p /tmp/inotify-test
inotifywait -m -e create,modify,move,delete /tmp/inotify-test別のセッションで、ファイルを作成し、変更します：
printf '最初の行n' > /tmp/inotify-test/probe.log
printf '二番目の行n' >> /tmp/inotify-test/probe.log最初のセッションは、少なくとも1つの作成と1つの変更を表示する必要があります。Ctrl+Cで停止し、もう必要のない場合はテストフォルダーを削除します。
私は設定の変更を行う前にこの確認を選びます。なぜなら、それはシンプルな質問に答えるからです：サービスは本当に期待されるディレクトリに到達していますか？それは書かれた内容の質について結論を出すものではありません。
本番環境におけるinotifywaitの限界
inotifyは、カーネルによって送信されたローカルイベントを監視します。非常に活発なディレクトリでは、出力が迅速に扱いにくくなり、イベントキューがオーバーフローする可能性があります。そうなると、アプリケーションログ、メトリクス、または適切な監査に戻る必要があります。
それをセキュリティ調査の唯一の証拠として使用しないでください。また、秘密が含まれているフォルダーや何千もの一時ファイルがあるフォルダーは避けてください。ファイルやポートを保持しているプロセスを特定するために、lsofは別の質問に答えます。
イベントとファイルの内容がテストアクションに一致する場合、診断を続けるためのクリーンな基礎があります。イベントが表示されない場合は、パス、systemdユニット、およびログのタイプを再確認してからサービスを変更してください。
オプションの正確な動作については、inotifywaitのマニュアルページを参照してください。