☰

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

tag-icon • tag-icon upstart init logrotate
Upstart がログローテーション時にログファイルを再度開かない

私たちは、Ubuntu サーバー上のサービスを管理するために upstart を使用しています。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

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

答え1

3つの選択肢があると思います。

  1. 「copytruncate」を追加して既存の設定を変更します

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

  2. 他のログ ファイルに影響がなく、既存の構成がそれらのログ ファイルに対して機能しているために、既存の logrotate 構成を変更できない (または変更が許可されていない) 場合は、必要に応じて「SERVICE_NAME.log」ファイルを /var/log の下の新しいフォルダーに移動し、「copytruncate」を使用して新しい構成を作成し、それを cron.daily に追加します。

  3. a) ホスト OS の logrotate 設定を変更したり、ホスト OS の cron.daily に追加したりできない場合、3 番目のオプションは、ファイルに書き込む前にファイルが存在するかどうかを確認するようにスクリプトまたはプログラムを変更することです。 b) 別の方法は、上記のポイント 2 と少し似ていますが、ログファイルを別の場所に移動し、スクリプトまたはプログラム内で、そのプログラムのログファイルに固有の logrotate コマンドを実行します。

上記のポイント 3b はよりトリッキーですが、よりエレガントであり、プログラムが自立的かつ自己管理され、OS のジョブによる監視を必要としないことを意味するため、私がほとんどの場合に使用するものです。

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

man logrotate

または

logrotate --help

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

答え2

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

おそらく、正しい方法は、 を/etc/logrotate.d/upstartすべて削除し、個々のサービスのファイルを個別にローテーションすることです。ディレクトリ ( /var/log/upstart/) には、さまざまなサービスの stdout/stderr のみが含まれており、デーモンこれら 2 つのチャネルに出力する必要があります。ただし、起動時だけは例外です。

私が管理しているシステムでは、、、の 3 つのサービスが upstart によって実行されます。3 つphp5.6-fpmのログはいずれもアクティブではありませphp7.1-fpmんacpidが、メイン ログ ファイル () がローテーションされたために fpm が再起動されることが/var/log/php5.6-fpm.logあります。起動時に何らかの無意味な出力が出力されるため、このノイズが発生します。

どうしてもこれらのファイルをローテーションする必要がある場合は、ファイルの名前がサービスの名前と一致するという事実を信頼して、次のpostrotateスクリプトを使用できます。

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

上記のことを機能させるには、必ずないそこに動詞を使用しますsharedscripts。私のスクリプトレットは、ファイルへの実際のパスが最初の引数 ( ) として渡されるという事実に依存しています$1。

(-command はノイズが多いため、へのリダイレクト/dev/nullが便利ですservice。また、cron によってそのようなノイズが電子メールで送られてくるのは望ましくありません。stderrここではリダイレクトしていませんstdout。問題が発生した場合、それに関する電子メールが引き続き送信されます。)

関連情報