How to find out which "unit" is logging to journalctl
I am working with usbmount and have finally got it working. One of the reasons it took me so long to get it working is that I thought the newest version of it (built from source) was not correctly mounting my drives as I could not see the mount command in the logs. I was using:
journalctl -u systemd-udevd.service -fto view the logs based on this blog post. The later version that I am now using though seems to be it's own service and does not log under that unit.
If I run just journalctl -f then I do see the logs that I am interested in:
Apr 23 06:51:35 raspberrypi systemd[1]: Starting ...
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/usb0but I get loads of other stuff as well (everythign in fact!). I have tried:
$ journalctl -u usbmount@.service -f
-- Journal begins at Mon 2022-04-04 13:05:58 BST. --but there are no logs. I have tried systemctl list-unit-files --all but there is nothing listed in there that looks like it might be the "unit" that I need to view usbmount logs. IN fact in the logs above you can see it say Starting so I am confused as to why this doesn't work!
1 Answer
First, the @ in usbmount@.service indicates it's a template unit. You can have , , etc., each of which instantiates the template with a parameter (foo, 1000, respectively). The names of these instantiated units are , respectively, and not the plain usbmount@service. So the name to be used with journalctl would be , respectively, and in your case, .
To just show logs from any usbmount service you can use a pattern in the unit name:
journalctl -u 'usbmount*'That said, you can tweak journalctl output to see more details. For example, there's --output=with-unit, which will show the exact unit name:
% 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 itSo the unit that produced this log entry is gdm.service.
You can also use --output=verbose to see everything there is to know about a log entry. Example:
% 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=/ _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=1650693687464817You can see in this case that the command for PID 703 is gdm (_COMM=gdm) and the unit is gdm.service (_SYSTEMD_UNIT=gdm.service).
There's also JSON output for easier machine parsing.
0
