journaltcl5日前に最後の再起動が完了しましたが、今日のみログが開始されるのはなぜですか？ :
$ journalctl -e | grep Logs.begin
-- Logs begin at Tue 2022-09-06 09:42:37 CEST, end at Tue 2022-09-06 11:04:27 CEST. --
$ last reboot | head -1
reboot system boot 3.10.0-1160.62.1 Thu Sep 1 23:46 - 11:04 (4+11:18)
$ journalctl -u scality-sfused
-- No entries --
$ egrep -v "^$|^#" /etc/systemd/journald.conf
[Journal]
RateLimitInterval=2s
RateLimitBurst=5000
ForwardToSyslog=yes
$ systemctl status scality-sfused | grep Warning
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
$ ls /etc/logrotate.d/scality-sfused
ls: cannot access /etc/logrotate.d/scality-sfused: No such file or directory
$
/var/lib/logrotate/logrotate.statusEDIT0：今日からです。
$ cat /var/lib/logrotate/logrotate.status | grep $(date +%Y-%-m-%-d)
"/var/log/scality/node/node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-1.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-3.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-11.log" 2022-9-6-3:11:1
"/var/log/scality-biziod.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-12.log" 2022-9-6-3:11:1
"/var/log/scality/backup/scality-backup.log.err" 2022-9-6-3:11:1
"/var/log/scality/node/node-11.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-2.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-2.log" 2022-9-6-3:11:1
"/var/log/scality/backup/scality-backup.log.out" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-12.log" 2022-9-6-3:11:1
"/var/log/scality/node/tier1sync-node-3.log" 2022-9-6-3:11:1
"/var/log/scality-srebuildd.log" 2022-9-6-3:11:1
"/var/log/scality/node/tier1sync-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-12.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-3.log" 2022-9-6-3:11:1
"/var/log/scality-sagentd.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-3.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-1.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-2.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-11.log" 2022-9-6-3:11:1
$
編集1：/etc/anacrontabファイルは次のとおりです。
$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job-identifier command
1 5 cron.daily nice run-parts /etc/cron.daily
7 25 cron.weekly nice run-parts /etc/cron.weekly
@monthly 45 cron.monthly nice run-parts /etc/cron.monthly
ベストアンサー1
ステータス出力を見ると、logrotateScalarアプリケーションのログが回転していることを確認できます。しかし、ここには少し混乱があります。二つ考慮すべきログセットlogrotate返される内容には影響を与えずjournalctl、ジャーナルド自身のファイルは管理されませんlogrotate。
日記帳
man systemd-journald.serviceJournaldが保存して報告する5つのログソースを一覧表示します。
カーネルログメッセージ
これはアプリケーションの動作によって影響を受ける可能性がありますが、アプリケーションの出力ではありません。名前はカーネルからのメッセージです。これはあなたが見ることができるものと同じです
dmesg。libc syslog(3) で呼び出される単純な syslog メッセージ
これは、永続サービスを含むアプリケーションが使用できる従来のロギング方法です。 systemd-journald（一緒にうまく動作する）の代わりに、または一緒に既存のsyslog実装を実行する場合
/var/logとmessages。syslogそれ以外の場合でも、ログにキャプチャされ、サービス階層に表示されます。ロガー自体がそうするように設定されていない限り、これはアプリケーションの制御範囲外のアプリケーション固有のファイルの使用を許可しないことに注意してください。 syslogに送信されるコンテンツは通常、アプリケーション名でタグ付けされますが、すべて一緒にまとめられています。これはカーネルメッセージも通常syslogによってキャプチャされるため、syslogはリアルタイムシステムイベントのインターリーブ記録であるため便利です。しかし、多くのアプリケーションではこれをまったく使用しておらず、私が知っている限り、これに賛成または反対する強力なルールはありません。 systemd自体はsyslogに書き込まれます。ジャーナルドでは、syslogはジャーナルドが提供できるものです。
基本Journal APIを介して構造化syslogメッセージを作成する
これはコマンドのジャーナルバージョンです
syslog。つまり、アプリケーションのソースコードで明示的に使用する必要があることを意味します。これがどれくらい一般的なのかはわかりませんが、デスクトップ環境、パッケージマネージャなどの重要なLinux中心の機能以外には大きな影響はありません。サービスユニットの標準出力と標準エラー。
これをキャプチャすることはsystemd-journaldのデフォルトの動作ですが、サービスファイルを介してさまざまな場所にリダイレクトすることもできます。
私の経験では、ほとんどの複雑なサービスアプリケーションではそれをあまり使用しません。
カーネル監査サブシステムから派生した監査記録
文脈上、これは実際には＃1のサブカテゴリです。
これはマンページに明示的には示されていませんが、デバイス固有のJournalctl出力には、問題のデバイスに関連するsystemdからのメッセージが含まれているようです（例
Starting XXXXX...：）。
これらのどれにも多くのコンテンツが含まれていません/var/log/scality。つまり、これらのファイルはログやsyslogとは関係ありません。
アプリケーションログ
私はScalityユーザーではありませんが、そこにあるコンテンツは間違いなく/var/log/scality外部からキャプチャしたものではなく、アプリケーションによって直接作成されたものです。
systemdまたはJournaldがこれらの機能を使用しない1つの明らかな理由は、プログラムがさまざまなファイルにデータを書き込んでそのプロセスを案内するいくつかの構成プロトコルがない場合、ジャーナリングなどの外部エンティティがレコードデータが何であるか、レコードが何であるかわかる方法がないからです。データ。いいえ。前述のように、アプリケーションがsyslogなどを使用するメカニズムがすでにあるため、そのようなプロトコルを使用する理由はあまりありません。
独自のログファイルをたくさん作成するタスクは、通常、タスクをきれいに保つように配置logrotateされます。 Logrotateはsystemdより前のバージョンであり、Journaldとは何の関係もありません。 Journaldは独自の永続ストレージ（存在する場合）を維持します。
簡単に言えば、「デバイスの起動後にログが回転しました」という元のメッセージは、いいえログが回転するからです。これはジャーナルド自身の運営の一部です。さらに、Scalityログインは/var/log/scalityJournaldではなくScality自体によって管理されます。