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