私は両者の関係を理解しようとしています、
/run/systemd/journal/dev-log
/run/systemd/journal/syslog
十分な明確なドキュメントが見つかりませんでした。ある意味で、それらは基本的に同じですか? syslog-ngの "unix-dgram()"にどちらかを含めると、ほとんど同じ出力が得られるからです。違いはありますか?とにかく、2つの間の関係は何ですか。
説明をありがとう。
方法がわかれば簡単です。
$ systemctl list-sockets
LISTEN UNIT ACTIVATES
...
/run/systemd/journal/dev-log systemd-journald-dev-log.socket systemd-journald.service
/run/systemd/journal/socket systemd-journald.socket systemd-journald.service
/run/systemd/journal/stdout systemd-journald.socket systemd-journald.service
...
25 sockets listed.
Pass --all to see loaded but inactive sockets, too.
わかりました、私はそれがとても簡単であることについて嘘をつきました。 syslogデーモンがないので、syslog.socketがアクティブ化されていません。しかし、それは私がドキュメントを見つけた場所です:
$ systemctl cat syslog.socket
# /usr/lib/systemd/system/syslog.socket
...
Documentation=man:systemd.special(7)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/syslog
...
# The default syslog implementation should make syslog.service a
# symlink to itself, so that this socket activates the right actual
# syslog service.
#
# Examples:
#
# /etc/systemd/system/syslog.service -> /lib/systemd/system/rsyslog.service
# /etc/systemd/system/syslog.service -> /lib/systemd/system/syslog-ng.service
#
# Best way to achieve that is by adding this to your unit file
# (i.e. to rsyslog.service or syslog-ng.service):
#
# [Install]
# Alias=syslog.service
#
# See http://www.freedesktop.org/wiki/Software/systemd/syslog for details.
https://www.freedesktop.org/wiki/Software/systemd/syslog/ は言う:
現在は/ dev/logでリッスンするジャーナルであり、もはやBSD syslogデーモンを直接ではないことに注意してください。ロギングデーモンがすべてのロギングデータにアクセスする必要がある場合は、systemdに同梱されているsyslog.socketユニットファイルを介して/ run/systemd/journal/syslogをリッスンする必要があります。 systemdシステムでは、/ dev/logを直接リッスンすることはもはや不可能であり、デーモンはそれ自体では/ run/systemd/journal/syslogソケットにバインドしない場合があります。これを行うと、サービス(およびその他のもの)のSTDOUT/STDERRからのロギングが失われます。
したがって、あなたの質問に対する答えは、unix-dgram()
でこれらのパスのいずれかを使用することは想定されていないということです。その下でsyslogデーモンとして実行する場合は、特定のsystemdサポートが本当に必要です。
個別の構成では、/run/systemd/journal/syslog
へのバインドを回避できるように思えます。これは、a)/dev/log
を所有する人を介してjournaldとの戦いを回避する、b)journaldが/dev/log
に決して書き込まれないサービスのSTDOUT/STDERRからそれにメッセージを書き込むため、間違いなく最も悪いオプションです。動作するように表示されることを考えると、ドキュメントにリストされている明示的な欠点はありません。明らかな欠点は、「syslog.target
...の初期ブートメッセージが実装に完全に失われた後に、ユニットを注文することをお勧めしなくなることです。」 「多くのサービスがsyslogの実装にログを記録できない」という警告もありますが、これは正しくないと思います/ /dev/log
でリッスンした場合にのみ当てはまります。