On 09/22/2014 08:50 PM, Canek Peláez Valdés wrote:
On Mon, Sep 22, 2014 at 7:41 PM, walt w41...@gmail.com wrote:
My main desktop machine is obviously having a brain fart :(
systemd-journald is allegedly obligated to write its journal files
to /var/log/journal/ *if* that directory exists, right?
Well, on my three other gentoo ~amd64 machines, that's exactly what
journald does.
But not on my everyday work machine, oh no. I'd be daft to expect
my one main everyday machine to obey the rules, right?
On this machine (the one I'm using now) journald is writing its
files to /run/log/journal/ instead of /var/log/journal/
# ls -l /var/log/journal/
total 4
drwxr-sr-x 2 root systemd-journal-remote 4096 Sep 22 14:39 remote
#ls -l /var/log/journal/remote/
total 0
The *.conf files in /etc/systemd/ are the same on all machines:
all of the config items are commented out, as sys-apps/systemd
installed them.
So, why is this particular machine not behaving like the others?
Hi Walt; the relevant documentation is from man 8 systemd-journald:
By default, the journal stores log data in /run/log/journal/. Since
/run/ is volatile, log data is lost at reboot. To make the data
persistent, it is sufficient to create /var/log/journal/ where
systemd-journald will then store the data.
So, in the failing machine the journal is not flushing its volatile
data to /var. I would suspect a permissions issue. Could you please
post the output from:
# ls -ld /var/log/journal
In my main machine, this is:
drwxr-sr-x 3 root systemd-journal 4096 Oct 28 2012 /var/log/journal
So its 2755; all permissions for root, read and execution (with SETGID
bit on), and read and execution for everyone else. The directory is
owned by root, and it's on the systemd-journal group.
Thanks, Rich and Canek. I fixed the problem by accident while trying
to debug it.
I used systemctl to stop and restart systemd-journald, thinking I might
see some useful error messages. But when systemd-journal started up
again the journal file was back in /var/log/journal where I want it :)
No idea why rebooting the machine didn't do the same thing.
Thanks.