☰

如何找出哪个“单元”正在向 journalctl 记录日志

tag-icon • tag-icon systemd systemd-journald
如何找出哪个“单元”正在向 journalctl 记录日志

我正在使用 usbmount，终于让它正常工作了。我花了这么长时间才让它正常工作的原因之一是，我认为它的最新版本（从源代码构建）没有正确安装我的驱动器，因为我在日志中看不到 mount 命令。我使用的是：

journalctl -u systemd-udevd.service -f

查看基于的日志这博客文章。不过，我现在使用的较新版本似乎是它自己的服务，并且不在该单元下登录。

如果我刚才运行journalctl -f，我确实会看到我感兴趣的日志：

Apr 23 06:51:35 raspberrypi systemd[1]: Starting [email protected]...
Apr 23 06:51:35 raspberrypi usbmount[925]: loaded usbmount configurations
Apr 23 06:51:35 raspberrypi usbmount[927]: trying to acquire lock /var/run/usbmount/.mount.lock
Apr 23 06:51:35 raspberrypi usbmount[930]: acquired lock /var/run/usbmount/.mount.lock
Apr 23 06:51:35 raspberrypi usbmount[949]: /dev/sda contains filesystem type vfat
Apr 23 06:51:35 raspberrypi usbmount[952]: mountpoint /media/usb0 is available for /dev/sda
Apr 23 06:51:35 raspberrypi usbmount[953]: executing command: mount -tvfat -osync,noexec,nodev,noatime,nodiratime /dev/sda /media/usb0

但我也得到了很多其他的东西（事实上是一切！）。我尝试过：

 $ journalctl -u [email protected] -f
-- Journal begins at Mon 2022-04-04 13:05:58 BST. --

但没有日志。我试过了，systemctl list-unit-files --all但其中没有列出任何看起来像是我需要查看 usbmount 日志的“单元”的东西。事实上，在上面的日志中你可以看到它这么说，所以我很困惑为什么这不起作用！Starting [email protected]

答案1

首先，@表示[email protected]模板单元。您可以拥有[email protected]、[email protected]等，每个实例都使用参数（分别为、）实例化模板foo。1000这些实例化单元的名称分别是[email protected]，[email protected]而不是普通的usbmount@service。因此，要使用的名称journalctl分别是[email protected]，[email protected]在您的例子中是[email protected]。

要显示任何usbmount服务的日志，您可以在单位名称中使用模式：

journalctl -u 'usbmount*'

也就是说，您可以调整journalctl输出以查看更多详细信息。例如，--output=with-unit将显示确切的单位名称：

% journalctl --output with-unit _PID=703 -n 1
Sat 2022-04-23 06:01:27 UTC muru gdm.service[703]: GLib: Source ID 163 was not found when attempting to remove it

因此，生成此日志条目的单位是gdm.service。

您还可以使用它--output=verbose来查看有关日志条目的所有信息。例如：

% journalctl --output verbose _PID=703 -n 1
Sat 2021-11-13 04:20:53.377000 UTC [s=6edbe8a0f4d644ac88a82448282c6f5b;i=2c4cb;b=977a8e5bf1c04b458502c8a9230477dc;m=b04611bd2;t=5dd4c12dfd4b7;x=e25d8723d4bd6c3c]
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=977a8e5bf1c04b458502c8a9230477dc
    _MACHINE_ID=06f3f1ec925e4a81834eee9c5c7da4fc
    _HOSTNAME=muru
    _UID=0
    _GID=0
    _TRANSPORT=syslog
    _CAP_EFFECTIVE=1ffffffffff
    PRIORITY=3
    SYSLOG_FACILITY=1
    SYSLOG_IDENTIFIER=gdm
    _PID=703
    _COMM=gdm
    _EXE=/usr/bin/gdm
    _CMDLINE=/usr/bin/gdm
    _SYSTEMD_CGROUP=/system.slice/gdm.service
    _SYSTEMD_UNIT=gdm.service
    _SYSTEMD_INVOCATION_ID=ee4611230c6b443d9eb5b362250d19b3
    SYSLOG_TIMESTAMP=Apr 23 15:01:27 
    MESSAGE=GLib: Source ID 163 was not found when attempting to remove it
    SYSLOG_RAW=<11>Apr 23 15:01:27 gdm: GLib: Source ID 163 was not found when attempting to remove it
    _SOURCE_REALTIME_TIMESTAMP=1650693687464817

您可以看到，在这种情况下，PID 703 的命令是gdm（_COMM=gdm），单位是gdm.service（_SYSTEMD_UNIT=gdm.service）。

还有 JSON 输出，以便于机器解析。

相关内容