Systemd-journaldは、syslogプロトコルの新しい実装なのか、それとも、rsyslog、syslog-ngなどのsyslog実装を使用しているのでしょうか。
私は少しググってみましたが、それについて説得力のあるものは何も見つかりませんでした。
プロトコルに関する限り、_systemd-journald
_…
/run/systemd/journal/stdout
_という名前のストリームソケットのリスナーです。 systemdは、サービスの生の標準出力とエラー(デフォルトであるか、明示的に_StandardOutput=journal
_/_StandardError=journal
_を持っている)をこのソケットに接続します。したがって、ラインフィードで終了する可変長の自由形式レコードのプロトコルを受け取ります。/run/systemd/journal/dev-log
_からシンボリックリンクされている_/dev/log
_という名前のデータグラムソケットのリスナーです。これは、アプリケーションにリンクされたGNU Cライブラリのsyslog()
ライブラリ関数が話すプロトコルを受け取ります。/run/systemd/journal/syslog
_という名前のデータグラムソケットをリッスンする別のサービスのクライアントになろうとします。これは、GNU Cライブラリのsyslog()
ライブラリ関数が話すプロトコルも受け取ります(ただし、_systemd-journald
_は、実際には別のライブラリと別の関数を使用してそれを読みます)。/dev/kmsg
_という名前のキャラクターデバイスのリーダーです。これは、Linuxカーネルが話すプロトコルを受け取ります。これは、可変長のプロトコルで、主にフリーフォーマットで、改行で終了します。/run/systemd/journal/socket
_という名前のデータグラムソケットのリスナーです。これは、GNU Cライブラリの場合に似ています。アプリケーションがこのソケットに対して特定のプロトコルを話すライブラリにリンクする点が異なります。関数がsd_journal_sendv()
であることを除いて、アプリケーションがリンクするsystemd Cライブラリ。プロトコルは標準化されていませんが、各データグラムにkey = valueペアの配列と、オプションで読み取り可能なファイル記述子を含むsystemd専用のプロトコルです。GNU Cライブラリのsyslog()
関数が話すプロトコルは、RFC 5424でもRFC 3164でもなく、事実上独自の事実上の標準です。RFC5424ではありません正しい量の空白文字と、NIL値を持つオプションフィールドを示すダッシュがないためです。PROCID
ではなくHOSTNAME
フィールドがあるため、RFC 3164ではありません。
数年前、systemdオペレーティングシステムは次のようなものでした。
systemd-journald
_上記のすべて(およびprotocolsに関しては無関係ないくつかのこと)を実行し、GNU Cライブラリとsystemd Cライブラリは、それぞれのプロトコルを使用して通信します/run/systemd/journal/syslog
_にメッセージを送信しようとしたときにxinetd
/inetd
スタイルで、ソケットをオープンファイル記述子として受信します。または、(rsyslogに相当する)imuxsock
モジュールを使用して_/run/systemd/journal/syslog
_を開き、リッスンするように構成されたストレートサービスとして。 GNU Cライブラリプロトコル現在、systemdオペレーティングシステムには次のものが含まれています。
systemd-journald
_再び上記のすべてを実行し、GNU Cライブラリとsystemd Cライブラリが通信するサーバーになります。imjournal
モジュールを使用してsystemdジャーナルファイルから物事を直接読み取るソケットではなく、ストレートサービスとして呼び出されるオプションのrsyslogプログラム