Linuxログインについて

簡単に言えば、おおよそ次のようになります。

カーネルはこの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。

もう一つの答えは、著者が言ったように、Linuxの「クラシックロギング」を説明しています。今日、多くのシステムはこのように動作しません。

コア

カーネル機構が変更されました。

カーネルはメモリバッファの出力を生成します。アプリケーションソフトウェアには2つの方法でアクセスできます。ロギングサブシステムは一般的に呼ばれる疑似FIFOでそれにアクセスします/proc/kmsg。このログ情報ソースは一度だけ読み取られるため、ログリーダー間で共有することはできません。複数のプロセスが共有する場合、各プロセスはカーネルログデータストリームの一部のみを取得します。また、読み取り専用です。

これにアクセスする別の方法は、最新の/dev/kmsgキャラクターデバイスです。これは、複数のクライアントプロセス間で共有できる読み取り/書き込みインターフェイスです。複数のプロセスがそれらを共有している場合は、互いに影響を与えずにすべて同じ完全なデータストリームを読み取ります。書き込みアクセス用に開くと、メッセージがカーネルから生成されたかのようにカーネルのログストリームにメッセージを挿入できます。

/proc/kmsg/dev/kmsgRFC-5424以外の形式でログデータを提供します。

適用分野

アプリケーションが変更されました。

GNU Cライブラリの主な機能は、名前付きデータグラムソケットsyslog()に接続し、ここにログエントリを書き込もうとします。 （BSD Cライブラリの関数はソケット名を取得して最初に試みます。）もちろん、アプリケーションはそれを直接実行するための独自のコードを持つことができます。結局のところ、ライブラリ関数はアプリケーション自体のプロセスのコンテキストで実行されるコード（ソケットを開く、接続、書き込み、閉じる）にすぎません。AF_LOCAL/dev/logsyslog()/var/run/log/var/run/logpriv

アプリケーションがコンピュータのAF_INET/ datagramソケットでリッスンしている場合は、UDPを介してローカルRFC 5426サーバーにRFC 5424メッセージを送信することもできます。AF_INET6

過去20年間、daemontoolsの世界の圧力により、多くのデーモンは、syslog()GNU Cライブラリ機能やUDPソケットを使用せずに、ログデータを通常のUnix方式で標準エラーとしてエクスポートするモードでの実行をサポートしています。

通常、ログ管理にはnoshとdaemontoolsシリーズを使用します。

daemontoolsツールスイートを使用すると、ロギングが非常に柔軟になります。しかし、一般的に、シリーズ全体のアイデアは、すべての「基本」デーモンに関連する「ロギング」デーモンがあるということです。 「デフォルト」デーモンはデーモンではないかのように動作し、ログメッセージを標準エラー（または標準出力）に記録し、サービス管理サブシステムはパイプ（ログデータが失われないように開いたまま）を介して接続を準備します。 。サービスの再起動）を「ロギング」デーモンの標準入力に送信します。

すべての「ロギング」デーモンはロギングプログラムを実行します。どこかに。通常、このプログラムは標準入力からmultilog読み取られcyclog、サイズが厳密に制限され、自動的に回転される書き込み専用ディレクトリにログファイルを書き込みます（ナノ秒タイムスタンプ）。通常、これらのデーモンは、権限のない専用ユーザーアカウントのスポンサー下でも実行されます。

したがって、各サービスのログデータが独立して処理される大規模分散ロギングシステムになります。

一つできるdaemontoolsシリーズサービス管理klogdに似たものを実行してくださいsyslogd。rsyslogdしかし、daemontoolsの世界は、「ロギング」デーモンを持つサービス管理構造がより簡単な方法で作業を実行するのに適していることを数年前に認識しました。すべてのログストリームを1つの巨大な雑誌に分散させ、ログデータを解析し、ストリームを別々のログファイルに分散させ、（場合によっては）信頼できない外部ログ回転メカニズムをサイドに追加する必要があります。ありません。標準ログ管理の一部であるdaemontoolsファミリの構造すでに完了しましたログの回転、ログファイルの書き込み、ストリームの分離。

さらに、すべてのサービスに共通のツールを使用して権限を削除するチェーンロードモデルは、ロガーにスーパーユーザー権限が必要ないことを意味します。 UCSPIモデルは、ストリーム転送とデータグラム転送と同じ違いにのみ関心が必要であることを意味します。

noshツールセットはこれを実装します。ひとつだけどできるその下で実行すると、デフォルトではrsyslogdカーネル/run/log、UDPログ入力を以前の方法で管理します。返品これを記録するためのより多くの「daemontools基本」方法が提供されています。

• klogdこのログストリームを読み込み、/proc/kmsg単に標準エラーに書き込むサービスです。これはという単純なプログラムを通して行われますklog-read。関連付けられたログデーモンは、標準入力のログストリームを/var/log/sv/klogdログディレクトリに提供します。
• local-syslog-read（BSDから）データグラムを読み取り、単に標準エラーにログストリームを書き込むサービスです。これはというプログラムによって行われます。関連付けられたログデーモンは、標準入力のログストリームをログディレクトリに提供します。/dev/log/run/logsyslog-read/var/log/sv/local-syslog-read
• udp-syslog-readUDP syslogポートでリッスンし、送信された内容を読み取り、標準エラーにログストリームを記録するサービス。繰り返しますが、このプログラムはですsyslog-read。関連ログデーモンは、標準入力のログストリームを/var/log/sv/udp-syslog-readログディレクトリに提供します。
• (BSD で)local-priv-syslog-readログ・ストリームからデータグラムを読み取り、/run/logpriv単にログ・ストリームを標準エラーに書き込むサービスです。繰り返しますが、このプログラムはですsyslog-read。関連ログデーモンは、標準入力のログストリームを/var/log/sv/local-priv-syslog-readログディレクトリに提供します。

ツールセットには、export-to-rsyslog1つ以上のログディレクトリを監視するためのツールも付属しています（非侵入システムを使用）。ログカーソル) RFC 5424 形式の新しいエントリをネットワーク経由で指定された RFC 5426 サーバに送信します。

ログ管理にsystemdを使用する

systemd-journaldsystemdには、systemdが管理するサービスとして実行される単一のフルログマネージャがあります。

• /dev/kmsgカーネルログデータを読み込みます。
• /dev/logGNU Cライブラリ関数（symlink-symlink）からアプリケーションログデータを読み込みます。/run/systemd/journal/dev-logsyslog()
• systemdが管理するサービスのログデータをAF_LOCALストリームソケットから受信します。/run/systemd/journal/stdout
• AF_LOCAL/run/systemd/journal/socketこれは、システム固有のロギングプロトコル（sd_journal_sendv()et al。）を使用するプログラムのログデータをデータグラムソケットから受信します。
• それはすべてを一緒に混ぜます。
• /run/log/journal/または、システム全体およびユーザー固有のログファイルセットに書き込みます/var/log/journal/。
• （クライアントとして）データグラムAF_LOCALソケットに接続でき/run/systemd/journal/syslog、syslogへの転送が設定されている場合は、そこにログデータを書き込みます。
• 設定されている場合は、書き込み可能なメカニズムを使用してカーネルバッファにログデータを書き込みます/dev/kmsg。
• 設定されている場合は、端末およびコンソールデバイスにもログデータを記録します。

プログラムがクラッシュしたりサービスが停止したりすると、システム全体に悪いことが発生する可能性があります。

systemd自体は、（特定の）サービスの標準出力とエラーがソケットに接続されるように準備します/run/systemd/journal/stdout。したがって、通常の方法で標準エラーに書き込むデーモンは出力をログに送信します。

これはklogd、syslogd、syslog-ng、およびrsyslogdを完全に置き換えます。

今、これらは具体的に体系化されなければなりません。 systemdシステムではできません/dev/log。代わりに、次の2つのアプローチのいずれかを取ります。

• /run/systemd/journal/syslog彼らは（覚えていれば）systemd-journald接続を試み、ログデータを記録するサーバー側になります。数年前に、imuxsockこれを行うようにrsyslogdの入力方法を設定できました。
• バイナリログ形式を理解し、ログファイルとディレクトリに追加される新しいエントリを監視するシステム固有のライブラリを使用して、システムログから直接データを読み込みます。今日、人々はimjournalrsyslogdの入力方法を設定してこれを行います。