☰

systemd-journal：dev-log 和 syslog 的关系是什么？

tag-icon • tag-icon systemd systemd-journald
systemd-journal：dev-log 和 syslog 的关系是什么？

我试图弄清楚两者的关系

/run/systemd/journal/dev-log
/run/systemd/journal/syslog

我找不到足够清晰的文档。从某种意义上来说，它们本质上是一样的吗？因为当我在 syslog-ng 的“unix-dgram()”中包含任一者时，我几乎得到相同的输出。有什么区别吗？无论如何，两者之间有什么关系呢？

感谢您的澄清。

答案1

当你知道如何做时，这很容易:)

$ 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 守护进程。如果您的日志守护进程想要访问所有日志数据，那么它应该监听 /run/systemd/journal/syslog，而不是通过 systemd 附带的 syslog.socket 单元文件。在 systemd 系统上，直接侦听 /dev/log 不再可行，并且您的守护程序可能无法自行绑定到 /run/systemd/journal/syslog 套接字。如果您这样做，那么您将丢失服务 STDOUT/STDERR 的日志记录（以及其他内容）。

因此，你的问题的答案是，你不应该将这些路径与unix-dgram().如果您想在 systemd 下作为 syslog 守护进程运行，您确实需要特定的 systemd 支持。

对于单独的配置，听起来您可能会摆脱绑定到/run/systemd/journal/syslog.这绝对是最不邪恶的选择，因为a）它避免了与journald争夺谁拥有/dev/log，b）journald将从服务的STDOUT/STDERR向其写入消息，而这些消息永远不会写入/dev/log。鉴于它出现为了工作，我看不到文档中列出的任何明显的缺点。明显的缺点是“我们不再建议人们在syslog.target……早期启动消息完全丢失后订购他们的设备。”还有一个警告“许多服务将无法登录到您的系统日志实现”，但我认为这是不正确的/仅适用于您收听/dev/log.

相关内容