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-journalLast 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