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

10

RHEL7では、systemd-journaldかつてによって行われていたことの多くの責任を引き継ぎrsyslogdます。バグによるか、これら2つのデーモン間の競合によるかは、場合/dev/logによっては行方不明になります。その結果、syslog(3)呼び出しに依存するプログラム（など）は正しく機能しませんlogger。/dev/logソケットを復元するにはどうすればよいですか？

systemd-journald rsyslogd

— オテウス
ソース

13

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

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

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

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

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

systemd-journald.socketを再起動します。
```
systemctl restart systemd-journald.socket
```
次にrsyslogdを再起動します
```
systemctl start rsyslogd
```

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

— オテウス
ソース

2

これを本当にありがとう！ロギングがサービスに対して機能しなかった理由を追跡して数時間失ったところです。私はついにそれを不足している/ dev / logまで追跡しました。それが私をあなたの解決策に導きました。

— Chad Huneycutt 2016

4

この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

— 11181
ソース

はい、手動でリンクすることもできます。しかし、覚えるのは少し扱いにくいです。質問：Ubuntuにはsystemd-journald.socketサービスとして存在しますか？Q2：多分それrestart rsyslogdは問題でしたか？多分それは単にあるべきstart rsyslogdですか？

— Otheus 2017年

Q1：はい、存在します。Q2：restartコマンドはもうありません、とがserviceあり/etc/init.d/rsyslogます。

— 11181

restart rsyslogdIそれが意味明確私だと思いましたsystemctl restart rsyslogd。Ubuntuはまだrsyslogのinitスクリプトを使用していますか？

— Otheus 2017年

@Otheusが/etc/init.d/rsyslog stop続いて/etc/init.d/rsyslog start助けにはならなかった。どちらもありませんでしたsystemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.service私のシステムでは/lib/systemd/system/rsyslog.service、両方あり/etc/init.d/rsyslogます。とにかく、この問題にもっと時間をかけたくない。

— 11181

0

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

でimuxsockのドキュメント彼らは、モジュールがsystemdにするために動作するようになっているかを歩きます。ステップ1で問題が発生しました。

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

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

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

それ以外の場合、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をエイリアスしようとすることも可能です。この場合、最後に有効にした方が優先されます。

— アダム
ソース