特定のサービスのログファイルの場所
Sudo journalctl -u {service}を使用すると、特定のサービスのログを確認できます。
- 関連するログファイルを見つける方法
- プログラムでログファイルを監視する最良の方法は何ですか？ （つまり、何かに基づいて反応するプログラムがログファイルに表示されます）
S6、runit、perp、nosh、daemontools-encoreなどを備えたシステムこのようにしてサービス管理作業を行います。各メインサービスには、個別に監視できるログファイルの個別の関連セットと、分散ロギングメカニズムがあります。
ただし、systemdはこの方法では機能しません。特定のサービスに個別の「関連付けられたログファイル」はありません。監視するファイルがありません。
すべてのログ出力は単一の中央デーモンsystemd-journaldに集められ、そのデーモンはすべてのサービスのログ出力が/{run,var}/log/journal/の単一の中央ジャーナルに結合された単一のストリームとして書き込みます。
journalctlの-uオプションは、単一の中央ジャーナルから出力されるものをフィルターにかける後処理フィルターであり、すべてのジャーナルエントリは、（関連して）関連するサービスの名前でタグ付けされています。すべてがファンになり、それをフィルタリングして元の状態に（ほぼ）分離する必要があります。
Systemdの方法は、適切なフィルターを追加してjournalctl -fを使用するか、ジャーナルのsystemd固有のAPIを使用して独自のプログラムを直接作成することです。
参考文献
1.）Linuxディストリビューションがjournaldを最大限に使用している場合、 @ JdeBP に記載されているように、簡単に読み取り可能な従来のログファイルはありません。ジャーナルファイルはバイナリ形式を使用しており、従来のログファイルツールでは簡単に解析できません。
2.）journalctl -u {service}に必要な情報がある場合、journalctl -f -u {service}を使用して、ログを解析し、必要な反応をトリガーするプログラムに出力をパイプすることができます。それを超えるものは、選択したLinuxディストリビューションに固有のものである可能性があります。
たとえば、デフォルト構成のDebian 9（Stretch）には、従来の/dev/log syslog入力ソケットを維持するjournaldがあります。ただし、rsyslogdがインストールされている場合、journaldは着信syslogメッセージを転送するように構成されています。
他のLinuxディストリビューションでは、journaldと、構造が異なる従来のsyslogデーモンとの関係がある場合があります。