You are not logged in.
Since the latest systemd update, I'm not able to read the system journal anymore:
[lynix@thor ~]$ journalctl
No journal files were found.
According to the man-page of `journalctl`, the user is granted acces only if he/she is in the systemd-journal group, which my user definitely is.
Using `strace` I discovered that `journalctl` is trying to read /run/log/journal/28b4e8e16867ef5e2f2ced63000003c2/system.journal, which is owned by root:root and mode 0640. This explains why `journalctl` fails to read the file.
Manually changing the group of the file to systemd-journal makes `journalctl` work again for my regular user.
So may this be an upstream bug (wrong file ownership) or am I doing something wrong here?
Last edited by lynix (2013-10-09 13:17:55)
Offline
Have you rebooted since the last systemd update? The way in which the journal's permissions are set has changed. So this setting is now enforced by a tmpfiles.d configuration. So you should check out /usr/lib/tmpfiles.d/systemd.conf. Maybe running the command in the systemd-tmpfiles-setup.service might help with things (it is /usr/bin/systemd-tmpfiles --create --remove --exclude-prefix=/dev ).
Offline
https://bugs.archlinux.org/task/37170
Edit: For me it's root:systemd-journal not root:root.
$ stat -c "%a %U %G" /var/log/journal/0dcc5d71ea3c9513b2b3b6e24aac1fee/system.journal
640 root systemd-journal
Last edited by karol (2013-10-05 19:48:19)
Offline
@WonderWoofy: thanks for the hint with /usr/lib/tmpfiles.d/systemd.conf!
@karol: joining your bug report. My quick 'n'dirty fix now is to modify the tmpfile config to touch /run/log/journal/... as well.
Offline
Ooohh, I totally missed that it is /run/log and not /var/log your journal is trying to read… meaning that your journal is not set to be persistent.
I think that what you have done should be fine, as an update to system *should* presumably have this modification included anyway. But if you want to make sure an update will not undo your handy work, move your added portion to a *.conf file in /etc/tmpfiles.d to ensure that it doesn't get overwritten by an update.
Don't forget to mark the thread as [Solved] if you are satisfied with things.
Offline
I haven't put the entries in /etc/tmpfiles.d just for the same reason: estimating an update to bring in the corresponding lines in /usr/lib/tmpfiles.d/systemd.conf - I'd like to have as few custom configuration files as possible
Already thought about marking the thread as 'solved', will do so now
Offline
If you have every expecatation that the fix will be in an update, then I would say that actually modifying the file in /usr/lib/tmpfiles.d might be an okay thing. This will provide a solution in the mean time, and be automatically wiped away during an update that (hopefully) fixes the issue.
Last edited by WonderWoofy (2013-10-09 15:53:50)
Offline