`file：` configを介してsystemdによって管理されているサービスのログを適切にログローテーションする方法
私はsystemdによって管理されているサービスを持っており、次のsystemd構成が、ログをファイルに直接書き込むようにsystemdに指示しています（syslogなどはありません）
StandardOutput=file:/var/log/foo/my.log
ログローテーションルールがあります
/var/log/foo/*.log
{
rotate 31
daily
missingok
notifempty
compress
delaycompress
sharedscripts
}
何が起こっているのかというと、ログはローテーションされていますが、サービスはまだ古いローテーションされたファイルに書き込んでおり、新しいログファイルは空のままです。
サービスが代わりにsyslogに書き込む同様の作業セットアップがあります。logrotate構成には次の機能があるため、これは正常に機能します。
postrotate
invoke-rc.d rsyslog rotate > /dev/null
、ログがローテーションされたことをsyslogに通知します。
問題は、私の問題のあるケースでは、ログがファイルに直接送信されるため、systemdまたは実際のサービスプロセスに同様のシグナルを送信する必要があるかどうか（またはどちらを送信する必要があるか）がわからないことです。
copytruncatelogrotateで問題を解決できると確信しているオプションを見つけましたが、これは理想的な方法ではないと感じていcopytruncateます。そうしないと、logrotateのデフォルトの動作になります。
この問題を解決するにはどうすればよいですか？systemdに信号を送信する必要がありますか？サービスプロセスにシグナルを送信する必要がありますか？copytruncate代わりにlogrotateで使用する必要がありますか？
重要な場合、サービスはログバックを使用してstdoutに書き込むJavaプロセスです。
回答
copytruncateこの場合の正解です。ログファイルを再度開くように通知できる適切なデーモンがあるため、これが必要になることはあまり一般的ではないため、デフォルトではありません。
別の方法は、ローテーション後のスクリプトでサービスを再起動することですが、これは便利ではないか、望ましくない場合があります。