systemd-journaldがsyslogプロトコルの新しい実装であるかどうか、rsyslog、syslog-ngなどのsyslog実装を使用しているかどうかを知りたいです。
グーグルをしてみましたが、説得力のある内容が見つかりませんでした。
ベストアンサー1
合意に関する限り、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()アプリケーションが接続するシステムCライブラリにあり、そのプロトコルは標準化されていません。各データグラムのキーと値のペアの配列と、オプションで人間が読み取ることができるファイル記述子を含むシステム専用プロトコル。
GNU Cライブラリの関数はsyslog()RFC 5424やRFC 3164ではないプロトコルを使用しますが、実際には独自の標準です。 NIL値でオプションのフィールドを指定するための正しい数のスペースとダッシュがないため、RFC 5424ではありません。PROCID代わりにフィールドがあるため、RFC 3164ではありませんHOSTNAME。
数年前、システムオペレーティングシステムは次のようになりました。
systemd-journald上記のすべてを行います（一部は規約）GNU Cライブラリとsystemd Cライブラリのサーバーになり、そのプロトコルを使用して通信します。- オプションのsyslog、rsyslog、またはsyslog-ngプログラムは、何かがソケットにメッセージを送信し、ソケットを開いたファイル記述子または開いて
xinetd受信するように構成された直接サービス（rsyslogと同じ）モジュールで受信しようとしたときに呼び出されます。 ; GNU Cライブラリプロトコルを指します。inetd/run/systemd/journal/syslog/run/systemd/journal/syslogimuxsock - オプションの syslog、rsyslog、syslog-ng、または udp-syslog-read サービスは RFC 5426 トラフィックを受信します。
現在のシステムオペレーティングシステムには以下が含まれる。
systemd-journald上記のすべての操作をやり直し、GNU Cライブラリとsystemd Cライブラリが通信するサーバーになります。- ソケットを介さずに直接サービスとして呼び出されるオプションのrsyslogプログラムは、そのモジュールを
imjournal使用してシステムログファイルから直接読み取ります。 - オプションの syslog、rsyslog、syslog-ng、または udp-syslog-read サービスは RFC 5426 トラフィックを受信します。