web-dev-qa-db-ja.com

systemd + rsyslogホストで「/ dev / log」を復元するにはどうすればよいですか？

RHEL7では、_systemd-journald_がrsyslogdによってかつて行われていたことの多くの責任を引き継ぎます。バグによるか、これらの2つのデーモン間の競合によるかに関わらず、_/dev/log_が欠落することがあります。その結果、syslog(3)呼び出しに依存するプログラムは、たとえばloggerを含め、正しく機能しなくなります。 _/dev/log_ソケットを復元するにはどうすればよいですか？

systemd-journaldrsyslogd
10
Otheus

Googleはこれについてあまり役に立たなかったので、自分の質問をして答える。

通常、rsyslogdを使用すると、imuxsockモジュールは独自に/dev/logソケットを作成し、以前のエントリをリンク解除してから作成します。 rsyslogdが停止している場合（おそらく、構成の誤りが原因で再始動が失敗したため）rsyslogdは削除されます/dev/log。

ただし、RHEL7で提供されるrsyslogは、systemdと組み合わせて使用​​することが想定されており、imuxsockモジュールは実際に/run/systemd/journal/syslogソケットを開いて削除します。一方、/dev/logデバイスは、journaldをトリガーするシステムサービスファイルsystemd-journald.socketによって作成されます。

どうやら、$imjournalモジュールが使用されているかどうかにかかわらず、次のように機能します。

つまり、/dev/logが消えた場合：

  1. systemd-journald.socketを再起動します。

    systemctl restart systemd-journald.socket

  2. 次にrsyslogdを再起動します

    systemctl start rsyslogd

更新：rsyslogdがすでに実行されている場合、restart rsyslogdがソケットを再度削除する可能性があると思います。

13
Otheus

systemctl restart systemd-journald.socket && systemctl restart rsyslogソリューションは、Ubuntu 16.04では機能しませんでした。

代わりに、/dev/logを/run/systemd/journal/dev-logへのシンボリックリンクとして再作成する必要がありました。

ln -s /run/systemd/journal/dev-log /dev/log
4
11181

私にとって、これは、rsyslogで使用されるimuxsockモジュールがsystemdでどのように機能しているかに問題があった。

imuxsockのドキュメント では、systemdでモジュールがどのように機能するかを説明しています。ステップ1で問題が発生しました。

手順1：システムソケットの名前を選択する

  1. ユーザーがSysSock.Use = "off"の設定を明示的に選択していない場合、デフォルトのリスナーソケット（別名「システムログソケット」または単に「システムソケット」）名は/ dev/logに設定されます。それ以外の場合、ユーザーが明示的にSysSock.Use = "off"を設定していると、rsyslogは/ dev/log OR SysSock.Nameパラメータで定義されたソケットとこの残りの部分をリッスンしません。セクションは適用されません。

  2. ユーザーがsysSock.Name = "/ path/to/custom/socket"を指定した場合（およびSysSock.Use = "off"を明示的に設定していない場合）、デフォルトのリスナーソケット名は/ path/to/custom/socketで上書きされます。

  3. それ以外の場合、rsyslogがsystemdで実行されていて、/ run/systemd/journal/syslogが存在する場合（かつユーザーが明示的にSysSock.Use = "off"を設定していない場合）、デフォルトのリスナーソケット名は/ run/systemd/journalで上書きされます。/syslog。

システムはステップ3に入り、デフォルトのパスを「/ run/systemd/journal/syslog」に変更する必要がありますが、代わりに「/ var/log」のままでした。これは、imuxsockモジュールが/ dev/logにソケットを作成しようと試み（場合によっては成功）、代わりにsystemd-journald-dev-log.socketによって作成されたシンボリックリンクが存在することを意味します。実際のソケットの作成に失敗した場合でも、シンボリックリンクは削除されます。

そのドキュメントは、rsyslog githubで報告された この問題 の結果でした。ディスカッションをスキップして変更に直接ジャンプする場合は、それぞれ PR＃1 および PR＃2 を参照してください。

私の解決策は、/ etc/rsyslog.confのsystemdパスを使用するようにimuxsockモジュールを構成することでした。

module(load="imuxsock"
    SysSock.Name="/run/systemd/journal/syslog")

これで私の問題は修正されたようで、手動で作成した後にシンボリックリンクが再び表示されなくなる理由を説明しているため、ここでは良い解決策のように思えます。

システムを調べて "/ run/systemd/journal/syslog"が存在しない場合は、 "syslog.socket"を調べて、それが正常に起動しているかどうかを確認します。これがソケットの作成の原因です。

systemctl status syslog.socket

Rsyslog.serviceのバージョンがsyslog.serviceを、syslog.socketがそのサービスをアクティブにしようとするときに必要なエイリアスとして定義していない可能性があります。複数のロギングサービスがsyslog.serviceをエイリアスしようとすることも可能です。この場合、最後に有効にした方が優先されます。

0
Adam