私が理解したところ、Linuxカーネルは/proc/kmsgファイル（主にハードウェア関連のメッセージ）と/dev/logソケットに書き込まれます。他にはありませんか？他のアプリで/proc/kmsgもメッセージを送信できますか/dev/log？最後に私の言葉は正しいですか？ syslogデーモン（システムログ、システムログ）2つの場所からのメッセージを確認し、そのメッセージをさまざまなファイル（中央のsyslogサーバーなど）に配布し/var/log/messagesます/var/log/kern.log。
ベストアンサー1
簡単に言えば、おおよそ次のようになります。
カーネルはこのprintk()関数を使用して、カーネル空間のリングバッファにメッセージを書き込みます。これらのメッセージは、ファイル/proc/kmsg（/procインストールされている場合）とsys_syslogシステムコールを介して2つの方法でユーザースペースアプリケーションに提供できます。
dmesg(1)カーネルのリングバッファを読み取ることができ、ある程度制御できる2つの主なアプリケーションがありますklogd(8)。前者は、リングバッファの内容を印刷するためにユーザの要求に応じて実行するように設計されている。後者は、メッセージを読み取り/proc/kmsg（またはインストールされていないsys_syslog場合は呼び出す）、またはコンソール/procに送信するデーモンです。syslogd(8)これはカーネルの側面を扱います。
ユーザースペースは、複数のUNIXドメインソケット（主にUNIXドメインソケットですが、他のものも構成できます）をsyslogd(8)リッスンし、オプションでUDPポート514から情報をリッスンするデーモンです。また、（関係ありません）/dev/logからメッセージを受信します。次に、設定されているように、これらのメッセージをいくつかのファイルまたは名前付きパイプに書き込むか、いくつかのリモートホスト（プロトコルを介してUDPポート514）に送信します。klogd(8)syslogd(8)/proc/kmsg/logsyslog/etc/syslog.conf
ユーザースペースアプリケーションは通常、このlibc機能を使用してsyslog(3)メッセージを記録します。 libcこれらのメッセージはUNIXドメインソケットに送信されますが/dev/log（これを介して読み取られるsyslogd(8)）、アプリケーションがchroot(2)-edの場合、メッセージは最終的に別のソケット（fiから）に書き込まれる可能性があります/var/named/dev/log。もちろん、これらのログを送信するアプリケーションはこれらのソケットの場所に同意することがsyslogd(8)重要です。このため、syslogd(8)標準ソケット以外のソケットでリッスンするように設定することができます/dev/log。
結局のところ、syslogプロトコルは単にデータグラムプロトコルです。アプリケーションの資格情報を使用してsyslog(3)機能を完全にバイパスしてソケットを開くことができる場合、アプリケーションがUNIXドメインソケットにsyslogデータグラムを送信するのを防ぐ方法はありませんlibc。データグラムの形式が正しい場合は、syslogd(8)メッセージを送信するのと同じように使用できますsyslog(3)。
もちろん、上記は「古典的な」伐採理論だけを扱っています。他のデーモン（たとえば、前述のデーモンrsyslogや前述のデーモンsyslog-ng）は通常のデーモンに代わるものsyslogd(8)であり、暗号化されたTCP接続を介してリモートホストにメッセージを送信する、高解像度タイムスタンプを提供するなど、あらゆる種類のクールなタスクを実行できます。また、systemdLinuxのUNIXの側面も徐々に浸食されています。 systemd独自のロギングメカニズムがありますが、その内容は他の人が話す必要があります。 :)
*BSD世界との違い：
* BSDでは使用できずklogd(8)、/proc存在しないか（OpenBSDで）ほとんど使用されません（FreeBSDおよびNetBSDで）。 syslogd(8)文字デバイスからカーネルメッセージを読み取り、/dev/klogそれをdmesg(1)使用して/dev/kmemカーネル名をデコードします。 OpenBSDだけが1つあります/dev/log。 FreeBSDは2つのUNIXドメインソケットを使用し/var/run/log、var/rub/logprivNetBSDは1つを使用します/var/run/log。