Linuxにおける基本的ログ理論
教科書的・基本的ログ理論（現代的なLinuxでは必ずしもそうではない
筆者はclassic logging theoryと述べている
カーネルスペースのリングバッファにprintk()関数を使って書き込み
疑似FIFO: メモリ上にある
このストリームにアクセスする方法
/proc/kmsgファイル
This source of log information cannot usefully be shared amongst log readers, because it is read-once. If multiple processes share it, they each get only a part of the kernel log data stream. It is also read-only.
ログの情報源（？）はログリーダーの間で共有されない。
複数のプロセスが共有した場合、プロセスはカーネルログのデータストリームの一部分しか得られない
sys_syslogシステムコール
/procがマウントされていない場合
/dev/kmsg
If multiple processes share it, they all read the same complete data stream, unaffected by one another. If they open it for write access, they can also inject messages into the kernel's log stream, as if they were generated by the kernel.
読み書き可能なデバイスで、複数のクライアント間で共有可能
複数のプロセスが同時にアクセスして、カーネルログのデータストリームにメッセージを注入できる
カーネルスペースのリングバッファにアクセスするアプリ
ユーザーが自分でコマンドを叩いてアクセス
/proc/kmsg（あるいはsys_syslog()）からのメッセージを読み取るデーモンがアクセスする
主に/dev/log
klogd(8)からのメッセージも受け取る
It then writes these messages to some files in /log, or to named pipes, or sends them to some remote hosts (via the syslog protocol, on UDP port 514), as configured in /etc/syslog.conf.
ユーザースペースのアプリは、libcのsyslog(3)を使う 内部では/dev/logにメッセージを送信し、syslog(8)はそれをリッスンする
UNIXドメインソケットの開放にクレデンシャルは必要だが、libcのsyslog(3)をバイパスして、ソケットに対してメッセージを送ることをとめられる他のアプリケーションは存在しない
ただし、データグラムが正しくフォーマットされていると、syslog(8)はsyslog(3)から送信されたかのようにそのデータグラムを利用できる
rsyslogなどの他のデーモンは、素のsyslog(8)を置き換えることがある 実際、/dev/logは/run/systemd/journal/dev-logへのシンボリックリンクになっている！
code:plain
stat /dev/log
File: /dev/log -> /run/systemd/journal/dev-log
Size: 28 Blocks: 0 IO Block: 4096 シンボリックリンク
Device: 0,6 Inode: 379 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-11-29 06:31:02.413121358 +0900
Modify: 2024-11-15 22:44:51.524784451 +0900
Change: 2024-11-15 22:44:51.524784451 +0900
Birth: 2024-11-15 22:44:51.524784451 +0900