3

logrotated を使用して、gunicorn アクセス ログをローテーションしています。これは私のログローテーション構成です

/opt/api/log/access.log {
    daily
    rotate 10
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
        killall -s USR1 gunicorn
    endscript
}

ログは正しくローテーションされ、圧縮され、新しい access.log が作成されます。ただし、gunicorn は古いログ ファイルへの「ポインタ」を解放しないため、ローテーションによって実際にディスク領域が解放されるわけではありません。

私はまだそれのエントリを見ることができますlsof

を実行するinitctl restart apiと、gunicorn が再起動し、ディスク領域が最終的に解放されます。

サービスを再起動するよりもクリーンな方法でディスク領域を解放するにはどうすればよいですか?

4

2 に答える 2

3

通常、Linux プロセスは、ログ ファイルのローテーションについて通知する特別なシグナルを受け入れます。この場合、システム上のSIGUSR1すべてのgunicornプロセスを処理するためにシグナルを送信しています。

質問は

  • そのようなプロセスは実行中のシステムに存在しますか

  • プロセスはシグナルgunicornを受け入れますかSIGUSR1

gunicorn のソース コードによると、USR1 は実際にログをローテーションする必要があります。

...だからkillall、コマンドが適切なプロセスに送信されないのではないかと思います。

これを確認するには、 でプロセス リストを確認してくださいps。プロセスが見つかった場合はgunicorn、変更workers/base.pyしてログ エントリを出力し、プロセスがシグナルを受信して​​いるかどうかを確認します。手でシグナルを送信してみてください。それが機能する場合、logrotate 構成が何らかの形で機能しません。

于 2014-06-10T17:03:29.143 に答える