inotifyが今使われているか分からないのですが、「今さら」の係り言葉は「CentOS 6」だったりします。
大変古いですが、バックエンドの奥の方に存在しているので、セキュリティリスクは低めだろうというのと、とにかくファイル数が多くて引っ越すのも大変、という理由で今のところ移し替えの予定はありません。
前提
- CentOS 6.6
- サーバのメモリは4GB
- ファイル数は
findとかで数えようと思っても1時間以上固まってしまうので不明。推定としては100万〜1000万くらい
導入
古いと導入にも障害があったりします。
echo "sslverify=false" >> /etc/yum.conf
wget http://vault.centos.org/centos/6/extras/x86_64/Packages/epel-release-6-8.noarch.rpm
rpm -Uvh epel-release-6-8.noarch.rpm
sudo sed -i "s/mirrorlist=https/mirrorlist=http/" /etc/yum.repos.d/epel.repo
yum --enablerepo=epel -y install inotify-tools
- rpmでepelを導入しようとすると古すぎて404になるので、vaultをwgetする
- SSL証明書で引っかかるのでSSL証明書確認をしない
- httpsじゃなくてhttpにアクセスする
設定
設定ファイルは下記を参考にさせていただきました。
パラメータ
/proc/sys/fs/inotify/max_user_watches というパラメータの値は 「8192」がデフォルト値なのですが、そのまま inotify を起動すると、 /var/log/messages に
Failed to watch /some_dir/; upper limit on inotify watches reached!
Please increase the amount of inotify watches allowed per user via (改行なし)
`/proc/sys/fs/inotify/max_user_watches'.
というエラーが出てプロセスが落ちます。
一方で、この値を大きくすると inotifywait 起動時にメモリ使用量がグーンと大きくなってしまうため、あまり一気に上げるのも危険です。
正直、勘所が分からないので倍々にしていったのですが、いつの間にか1桁間違ってしまった（つまり約20倍にした）上、1000万以上で設定していた → それでも落ちた ので、2000万にしたら最後まで行った感じです。（1000万以上の値で落ちたので、ファイル数は1000万以上2000万以下なのかもしれません）
起動後
起動後、対象ディレクトリのファイル情報の収集が始まるようです。
今回はファイル数がおそらく1000万〜2000万で、2時間弱かかりました。（スペック次第と思われる）
この情報収集の間は、ロードアベレージが純粋に1上がります。
また、この情報収集の間に対象ディレクトリにファイルをアップしても、ログファイルには記録されません。
この間にファイルを上げるのに影響があるかも、と思ったのですが、特に影響はありませんでした。
inotifywait プロセスのメモリ消費量は、情報収集中は時間経過とおそらく正比例に増えていきます。最終的には、VIRT 148MB、RSS 143MBの消費量となりました。今回は4GBあったので余裕がありましたが、1GBとかだと場合によっては厳しいかもしれません。
auditd はダメでした。
inotifyを試す前に auditd （ -w /some_dir/ -p wa -k file_change ）を試していたのですが、バージョンによって「指定ファイルまたは指定ディレクトリのみ」が対象になるものと、「指定ディレクトリ 以下」 が対象になるバージョンがあるようで、CentOS6に入っている auditd では、今回は指定ディレクトリ のみ だったため、使うことができませんした。