web-dev-qa-db-ja.com

Ubuntu 13.XのUpstartログメッセージはどこにありますか？

Ubuntu 12.04では、/var/log/syslogにUpstartログメッセージがあります。

コマンド：

# 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では、/var/logなどのコマンドは正常に機能しますが、メッセージはsyslogまたはlogger helloディレクトリの下のどこにも表示されません。他の場所で探してください。どこかに変更する必要がある構成設定はありますか？

Ubuntu 13.04で同じ問題を抱えていると思われる誰かからの サーバー障害に関する質問 があり、さらに here および here 同じ問題を説明します。残念ながら、これらの質問は問題の原因にはなりません。

13.10upstartloggingsyslog
28
Bradd Szonye

編集2016-06-02

一般に「Upstartログメッセージ」を見つけようとしている場合は、/var/log/upstart/を確認してください。 Upstartは、Upstartサービスからstdoutとstderrを保存します。これを指摘してくれたleopdの回答に感謝します。

Upstart自体からのログメッセージを探している場合は、initctl log-priorityで構成され、initctl emitで出力されます。読み進めてください！

短縮版

ログエントリは、実際にはdmesgに表示されるはずです。それにもかかわらず、デフォルトでは/var/logにnotが表示されます。

それらも/var/logに入れたい場合は、$KLogPermitNonKernelFacility onをrsyslogdの設定に追加してください。 /etc/rsyslog.d/60-custom.confのようなカスタムファイルを作成して、/etc/rsyslog.confの編集を避けることをお勧めします。これはdpkgによって管理されているためです。 Upstartの/var/log/syslogをinfoに設定すると、Upstartメッセージがlog-priorityに表示されるようになります。

ロングバージョン

これを追跡するのに何日もかかりましたが、明らかにUpstart（1.5）はsyslogにnotログを記録します。つまり、glibc関数syslog()を呼び出しません。代わりに、Upstartはdmesgが読み取るカーネルリングバッファーにログを記録します。今、ユーザー空間プロセスがそのバッファーに書き込むことは可能だとは思いませんでしたが、明らかに/dev/kmsgに書き込むことで可能です、そしてそれがまさにUpstartの仕事です。これがパズルの最初の部分です。

2番目の部分は、カーネルリングバッファーに書き込まれたメッセージがカーネルによって自動的にsyslogにコピーされるという広く信じられていることです（少なくとも、私は常に考えていました）。これは、実際にはsyslogdと連携して動作するユーザースペースデーモン（従来はklogd）によって行われます。明らかに、rsyslogdはsyslogdを置き換えますが、明らかにklogdも置き換えます（並べ替え：末尾の注を参照）。

3番目の部分は、ユーザー空間からカーネルリングバッファーに書き込まれたメッセージは、実際にはカーネル空間から書き込まれたメッセージとは異なるように見えることです。つまり、機能が異なります。 dmesgには、これと対話するいくつかのオプションがあります。-xは機能（および優先度）を表示し、-uおよび-kはdmesgにユーザー機能メッセージとカーネル機能メッセージのみを表示するよう指示します。それぞれ。

これがクリンチャーです。デフォルトでは、カーネルリングバッファーからメッセージを読み取るときに、非カーネル機能を備えたrsyslogdignoresメッセージが表示されます。関連する設定オプションは$KLogPermitNonKernelFacilityです。これはデフォルトでオフになっており、rsyslogdでこれらのメッセージを処理する場合はオンにする必要があります。 rsyslogdの残りの設定は、カーネルリングバッファーにある機能に関係なく、カーネルリングバッファーからのすべてのメッセージをkern機能を持つものとして扱うことに注意してください。

詳しくは

syslog

コードは、man 3 syslogで説明されているglibc関数syslog()を呼び出すことでsyslogに書き込むことができます。明らかにこれらの関数は/dev/logに書き込みます。コードは/dev/logを読み取ることでsyslogから読み取ることができます。これはsyslogdとその置換が行うことです。 rsyslogdは、imuxsock入力モジュールを使用して/dev/logを読み取ります。

カーネルリングバッファー

カーネル関数は、カーネル関数printk()を呼び出してこのバッファーに書き込みます。したがって、printkバッファーと呼ばれることもあります。ユーザースペースは、/dev/kmsgに書き込むことで書き込みできます。ユーザー空間は、いくつかの方法でこのバッファから読み取ることができます：/proc/kmsg（デフォルトではdmesgが行うこと）から読み取るか、/dev/kmsgから読み取るか、システムコールsyslog()を呼び出すman 2 syslogで説明されており、man 3 syslogで説明されているglibc関数syslog()とは完全に異なります。 glibcは、実際にはsyslog()と呼ばれるシステム呼び出しklogctl()にラッパーを提供し、この混乱を軽減します。

従来、klogdはこれらのインターフェイスの1つから読み取り、glibc関数syslog()を呼び出してsyslogにコピーします。 rsyslogdはimklog入力モジュールを介してこれらのインターフェイスの1つを読み取りますが、AFAIKはglibc syslog()を呼び出さないため、klogdとまったく同じではありません。他の入力モジュールからの出力を処理するのと同じように、imklogの出力を処理するだけです。カーネルリングバッファーにあるファシリティメッセージに関係なく、すべてのimklog出力にkernファシリティがあるという警告が追加されています。

参照資料

39
Vanessa Phipps

私は/var/log/upstart/で私のものを見つけました

16
Leopd