ログローテーション時にUpstartがログファイルを再度開かない

私たちはUbuntuサーバーでサービスを管理するためにupstartを使用しています。/var/log/upstart/SERVICE_NAME.logにログアウトされるログを生成します

その後、毎日、ログファイルは12.04 LTSに付属するlogrotationスクリプトを使用してローテーションされます。

/var/log/upstart/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        nocreate
}

問題は、logrotateがファイルを移動している間、upstartがファイルを閉じて再度開くように通知せず、upstartプロセスが削除PIDに書き込んでいることです。

init          1       root    8w      REG              202,1        64       2431 /var/log/upstart/dbus.log.1 (deleted)
init          1       root   13w      REG              202,1        95       2507 /var/log/upstart/acpid.log.1 (deleted)
init          1       root   14w      REG              202,1       127      17377 /var/log/upstart/whoopsie.log.1 (deleted)
init          1       root   36w      REG              202,1       122       6747 /var/log/upstart/SERVICE_NAME.log.1 (deleted)
init          1       root   37w      REG              202,1        30       6762

当然、自分のサービスからの出力を他のログファイルにリダイレクトすることもできますが、システムプロセスの問題は依然として存在します。また、必要以上のインフラストラクチャを構築する必要はありません。

upstart init logrotate

— アンドリューニューディゲイト
ソース

私もこれに遭遇したばかりです。今まで気づかなかったのは奇妙なことで、最近のことかもしれません。

— pwaller 2014年

これに関する更新はありますか？14.04でまったく同じ問題が発生します。そのnocreateディレクティブのため、なぜ誰もがこのディレクティブを使用する理由が

— わかり

これも経験しています。

— Ztyx 2015年

私はこのバグ

— Lety

回答:

3つのオプションがあると思います。

「copytruncate」を追加して既存の構成を変更します

/var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }
影響を受けない他のログファイルが原因で既存のlogrotate構成を変更できないか（許可されていない）、既存の構成が機能する場合は、「SERVICE_NAME.log」ファイルを/の下の新しいフォルダーに移動しますvar / logを使用する場合は、「copytruncate」を使用して新しい構成を作成し、それをcron.dailyに追加します。
a）ホストos logrotate構成の変更またはホストOSのcron.dailyへの追加が許可されていない場合、3番目のオプションは、ファイルに書き込む前にファイルが存在することを確認するようにスクリプトまたはプログラムを変更することです。b）別の方法は、ログファイルを別の場所に移動し、スクリプトまたはプログラム内で、そのプログラムのログファイルに固有のlogrotateコマンドを実行することです。

上記のポイント3bは、よりトリッキーですがよりエレガントです。これは、プログラムが自給自足で管理され、OSのジョブを必要としないため、ほとんどの場合に使用します。

logrotateを手動で実行してプログラムまたはスクリプトに追加する方法を見つけるには、次のように入力します。

man logrotate

または

logrotate --help

プログラムにPythonを使用している場合は、このプログラムがPythonを使用してログファイルを自己管理する方法を確認できます。 http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

— DanglingPointer
ソース

これは既知の問題であり、これを入力してもチケットは開いたままです。

正しいことは、おそらく、/etc/logrotate.d/upstart完全に削除して、個々のサービスのファイルを個別にローテーションすることです。ディレクトリ（/var/log/upstart/）にはさまざまなサービスのstdout / stderrのみが含まれているため、デーモンとして実行するサービスはこれらの2つのチャネルに出力されません。たぶん、まさしく、まさにスタートアップで。

私が管理していますシステムでは、3つのサービスは、成り上がりによって運営されていますphp5.6-fpm、php7.1-fpmとacpid。3つのログはいずれもアクティブではありませんが、メインのログファイル（/var/log/php5.6-fpm.log）がローテーションされているためにfpmが再起動される場合があります。起動時にいくらか不自然さが出力されるため、このノイズが発生します。

とにかくこれらのファイルのローテーションを主張する場合は、ファイルの名前がサービスの名前と一致し、次のpostrotateスクリプトを使用するという事実に依存できます。

    postrotate
            service=${1##*/}
            service=${service%.log*}
            service $service restart > /dev/null
    endscript

上記が機能するためには、そこで動詞を使用しないように~~sharedscripts~~してください-私のスクリプトレットは事実に依存しています。ファイルへの実際のパスが最初の引数（$1）として渡されます。

（- へのリダイレクト/dev/nullは便利です。service-commandはノイズが多く、cronからこのようなノイズが電子メールで送信されることを望まないためです。私はstderrそこにリダイレクトしていません。stdout問題がある場合のみ、それについてはまだあなたの電子メールを受け取ります。）

— ミハイル・T
ソース