48

I am running user-level services in Ubuntu 16.04 LTS. For example, I have my test.service located at ~/.config/systemd/user/test.service.

I was able to run the service by doing

systemctl --user start test.target

However, when I try to read its log using journalctl, I got this error message:

journalctl --user -u test.service
Hint: You are currently not seeing messages from other users and the system.
  Users in the 'systemd-journal' group can see all messages. Pass -q to
  turn off this notice.
No journal files were opened due to insufficient permissions.

How can I use journalctl for user's specific unit?

Alexis Wilke
  • 2,210
  • 1
  • 20
  • 37
ChromeHearts
  • 600
  • 1
  • 4
  • 8
  • FTR, I'm not sure if it's the same situation, but what helped for me is adding the user to `systemd-journal` group with `sudo usermod -aG systemd-journal user` and then logging out/log in. – Hi-Angel Aug 08 '23 at 07:30

3 Answers3

28

On older systemd versions, you'll have to use journalctl --user --user-unit=SERVICENAME (on newer versions journalctl --user -u SERVICENAME will work fine).

However, this only works if the Storage directive of the [Journal] section of /etc/systemd/journald.conf is set to persistent (instead of auto or volatile). Reboot after editing the configuration file and the user will be able to see the journal.

More information: https://www.freedesktop.org/software/systemd/man/journald.conf.html https://lists.freedesktop.org/archives/systemd-devel/2016-October/037554.html

D Schlachter
  • 396
  • 3
  • 4
  • 3
    Adding the user to the systemd-journal group was the answer I needed (from that mailing list link). – Travis Well Jun 30 '17 at 21:41
  • This worked for me on Ubuntu 17.10, where one user inexplicably couldn't view his logs, while another could. – datu-puti Dec 21 '17 at 18:04
  • 4
    Adding a user to the systemd-journal group would be a workaround, but since my service was a user service, I don't think the logs were generated in the first place, so allowing my user to view all the other logs wouldn't have helped anyway. – datu-puti Dec 21 '17 at 18:10
  • 3
    `journalctl --user-unit SERVICENAME` works fine even with storage set to volatile. But any of `-u SERVICENAME`, `--user -u SERVICENAME` or `--user --user-unit SERVICENAME` do not work with volatile storage, they all just show "no entries". – Kankaristo Nov 05 '21 at 21:14
  • 1
    You dont need to restart the box, you can just run `systemctl restart systemd-journald` after making the change to `/etc/systemd/journald.conf`. Also the user in question MUST have a uid > 1000 (non system user). if you want to run journalctl commands inside of a different systemd --user unit. – Dave Mar 21 '22 at 22:51
  • on systemd 239, you need just `journalctl --user-unit SERVICENAME` without the `--unit` ! And it does not require the user to be in the `systemd-journal` group either. – xealits Jul 05 '23 at 14:54
2

I was not able to make it work with the --user and other such options. However, I can see the data when I use journalctl on its own. It includes all the logs, though. I can search the specific app I'm interested in and look at that output. To find the latest, I first go at the end of the file then search backward:

  1. Hit G to go to the end (it's a capital G)

  2. Hit ? and enter your apps name

It's not as practical, but on the device on which I work (a Jetson), that was pretty much the only way I found to make it work.

Alexis Wilke
  • 2,210
  • 1
  • 20
  • 37
0

you can make a bash script that rans sudo journalctl with specific parameter, protect that script from writing, give specific permission to run that script as sudo with no password. add entry in /etc/sudoers as for example

ALL ALL = NOPASSWD: /etc/show_journal.sh

instead of ALL your can write a specific linux user

Nir O.
  • 111
  • 3
  • This solution is a workarround, since there is no ACL in the journalctl... – MUY Belgium Apr 12 '23 at 14:43
  • this is a general solution to customize a specific allowance for accessing system logs, for users who are not root nor `systemd-journal` users (giving inclusive `systemd-journal` access can be risky because `systemd-journal` opens access to sensitive security info) – Nir O. Apr 17 '23 at 09:19