Ubuntu 12.04では、Upstartログメッセージは/var/log/syslogにあります。 。
コマンド：
# initctl log-priority info
# initctl emit hello
ログ：
Apr 1 01:56:56 precise64 kernel: [ 8365.820425] init: Connection from private client
Apr 1 01:56:56 precise64 kernel: [ 8365.821130] init: Handling hello event
Ubuntu 13.10では、メッセージはsyslogに表示されません または/var/logの下の任意の場所 ディレクトリ。ただし、logger helloなどのコマンド 期待どおりに動作します。私はどこかでそれらを探すべきですか？どこかで変更する必要のある構成設定はありますか？
Ubuntu 13.04で同じ問題を抱えていると思われる人からのサーバー障害に関する質問があります。こことここで、同じ問題を説明している可能性があります。残念ながら、これらの質問は問題の原因にはなりません。
ベストアンサー
編集2016-06-02
一般に「Upstartログメッセージ」を検索する場合は、/var/log/upstart/を確認してください。 。ここで、Upstartはstdoutを保存します およびstderr Upstartサービスから。これを指摘してくれたleopdの回答に感謝します。
Upstart自体からのログメッセージを探している場合は、initctl log-priorityによって構成されます。 initctl emitによって発行されます 、読んでください！
ショートバージョン
ログエントリは実際にはdmesgに表示されます。それにもかかわらず、彼らはしません デフォルトでは/var/logに表示されます 。
/var/logにそれらが必要な場合 また、$KLogPermitNonKernelFacility onを追加します rsyslogdの構成に。 /etc/rsyslog.d/60-custom.confのようなカスタムファイルを作成することをお勧めします /etc/rsyslog.confの編集を避けるため 、それはdpkgによって管理されているからです。これで、Upstartメッセージが/var/log/syslogに表示されるはずです。 、Upstartのlog-priorityを設定したら infoへ かそこら。
ロングバージョン
これは追跡するのに数日かかりましたが、どうやらUpstart（1.5）はしません syslogにログを記録します。つまり、glibc関数syslog()を呼び出しません。 。代わりに、Upstartはカーネルリングバッファにログを記録します。これはdmesgが読み取るものです。さて、可能だとは思いませんでした ユーザースペースプロセスがそのバッファに書き込むために使用しますが、明らかに/dev/kmsgに書き込むことで可能です。 、そしてそれはまさにUpstartが行うことです。これがパズルの最初の部分です。
2番目の部分は、カーネルリングバッファに書き込まれたメッセージがカーネルによって自動的にsyslogにコピーされるという広く信じられている信念があります（少なくともそれは私がいつも思っていたものです）。これは実際には、syslogdと連携して動作するユーザースペースデーモン（従来はklogd）によって実行されます。明らかに、rsyslogdはsyslogdを置き換えますが、明らかにklogdも置き換えます（一種：最後の注を参照してください）。
3番目の部分は、ユーザースペースからカーネルリングバッファーに書き込まれるメッセージは、実際にはカーネルスペースから書き込まれるメッセージとは異なって見えることです。つまり、機能が異なります。 dmesgには、これと相互作用するいくつかのオプションがあります：-x -uが機能（および優先度）を表示します および-k ユーザーファシリティメッセージとカーネルファシリティメッセージのみをそれぞれ表示するようにdmesgに指示します。
これがクリンチャーです。デフォルトでは、rsyslogdは無視します カーネルリングバッファからメッセージを読み取るときに、カーネル以外の機能を持つメッセージ。関連する構成オプションは$KLogPermitNonKernelFacilityです。 、これはデフォルトでオフになっており、rsyslogdでこれらのメッセージを処理する場合はオンにする必要があります。 rsyslogdの残りの構成は、カーネルリングバッファからのすべてのメッセージをkernを持つものとして扱うことに注意してください。 カーネルリングバッファにあるファシリティに関係なく、ファシリティ。
詳細情報
syslog
コードは、glibc関数syslog()を呼び出すことにより、syslogに書き込むことができます。 、man 3 syslogで説明されています 。どうやらこれらの関数は/dev/logに書き込みます 。 /dev/logを読み取ることで、syslogからコードを読み取ることができます。 、これがsyslogd そしてその代替品はそうです。 rsyslogd /dev/logを読み取ります imuxsockを使用する 入力モジュール。
カーネルリングバッファ
カーネルスペースは、カーネル関数printk()を呼び出すことにより、このバッファーに書き込みます。 、したがって、printkバッファと呼ばれることもあります。ユーザースペースは、/dev/kmsgに書き込むことで書き込むことができます 。ユーザースペースは、いくつかの方法でこのバッファーから読み取ることができます。/proc/kmsgから読み取ることができます。 （dmesgがデフォルトで行うこと）、または/dev/kmsgから読み取ることができます 、またはシステムコールsyslog()を呼び出すことができます 、man 2 syslogで説明されています 完全に異なる glibc関数syslog()から man 3 syslogで説明されています 。 glibcは、実際にはシステムコールsyslog()のラッパーを提供します 、klogctl()と呼ばれます 、この混乱を緩和するのに役立ちます。
伝統的に、klogd これらのインターフェイスの1つから読み取り、glibc関数syslog()を呼び出します。 それらをsyslogにコピーします。 rsyslogdは、imklogを介してこれらのインターフェースの1つを読み取ります 入力モジュールですが、AFAIKはglibc syslog()をわざわざ呼び出すことはありません。 、それがklogdとまったく同じではない理由です。 imklogの出力を処理するだけです 他の入力モジュールからの出力を処理するのと同じように。すべてのimklogに追加の警告があります 出力にはkernがあります カーネルリングバッファにあるファシリティメッセージに関係なく、ファシリティ。
参照
- http://upstart.ubuntu.com/cookbook/#initctl-log-priority（Upstartがsyslogにログを記録すると誤って記載されています）
- https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg
- http://www.gnu.org/software/libc/manual/html_node/Overview-of-Syslog.html
- http://www.rsyslog.com/doc/v5-stable/configuration/modules/imklog.html（これは、Ubuntu 12.04で使用されるv5用であることに注意してください。これらのオプションは、最近のrsyslogバージョンではレガシーと見なされます）