You are not logged in.

#1 2015-02-11 19:33:32

bodo
Member
From: Slovakia
Registered: 2007-10-29
Posts: 8
Website

No journal files were found, for journalctl.

Hello,

May be it's a dumb question, but is there a reason why journalctl won't create journal file in /var/log?

[@arch]# journalctl
No journal files were found.

Beware that my /var/log is mounted as:

#/var/log
/var/log        /var/log    tmpfs        nodev,nosuid                0 0

If I uncomment it, so /var/log is now mounted on my SSD disk, journalctl will create /var/log/journal file and I'm able to use journalctl to read the log.

Any advise are welcome, thank you.

Last edited by bodo (2015-02-11 19:34:07)

Offline

#2 2015-02-11 19:40:18

r0b0t
Member
From: /tmp
Registered: 2009-05-24
Posts: 505

Re: No journal files were found, for journalctl.

- syslog not runnnig?
- no more space?
- I/O errors and files can't be written?
- /usr/lib/systemd/systemd-journald not running?
- storage set to "auto" to /etc/systemd/journald.conf ?
-  If you or some program delete that directory, systemd will not recreate it automatically; however, it will be recreated during the next update of the systemd package. Until then, logs will be written to /run/systemd/journal, and logs will be lost on reboot.
https://wiki.archlinux.org/index.php/Systemd#Journal

Offline

#3 2015-02-11 20:07:27

dice
Member
From: Germany
Registered: 2014-02-10
Posts: 413

Re: No journal files were found, for journalctl.

you should check if /var/log is writeable when mounted as tmpfs.
Also check the output of

mount

for mount flags that are set by default. For example it might be the case that for some reason your /var/log gets mounted read only.


I put at button on it. Yes. I wish to press it, but I'm not sure what will happen if I do.  (Gune | Titan A.E.)

Offline

#4 2015-02-12 08:02:14

bodo
Member
From: Slovakia
Registered: 2007-10-29
Posts: 8
Website

Re: No journal files were found, for journalctl.

dice wrote:

you should check if /var/log is writeable when mounted as tmpfs.
Also check the output of

mount

for mount flags that are set by default. For example it might be the case that for some reason your /var/log gets mounted read only.

It's mounted as rw, I suppose from mount output:

/var/log on /var/log type tmpfs (rw,nosuid,nodev,relatime)

also

drwxr-xr-x  3 root root    140 Feb 12 07:46 log

So it must be something else.

Offline

#5 2015-02-12 09:17:56

Spider.007
Member
Registered: 2004-06-20
Posts: 1,175

Re: No journal files were found, for journalctl.

bodo wrote:

[...]

So it must be something else.

So how about checking the issues mentioned by r0b0t? I'm pretty sure you're experiencing one of the issue he mentions

Offline

#6 2015-02-12 10:06:24

bodo
Member
From: Slovakia
Registered: 2007-10-29
Posts: 8
Website

Re: No journal files were found, for journalctl.

Ok, I've got it! The trick was to configure

/etc/systemd/journald.conf

with option

[Journal]
Storage=volatile

Now it's logging to

/run/log/journal

Thanks all of you.

Offline

#7 2015-02-12 12:47:23

snakeroot
Member
Registered: 2012-10-06
Posts: 164

Re: No journal files were found, for journalctl.

The issue with this approach is that it will make it very difficult to debug serious, freeze-the-machine, force-to-reboot grade issues, since the journal will be stored only in RAM and thus lost on reboot.

Given your desire to protect your SSD, would it make sense to reset Storage to persistent but reset MaxLevelStore to something pretty high (emerg, alert, crit) from its default level of "debug"? That way you'd have a permanent record on disk of truly bad things, but not the wear and tear of writing every little thing.

Regards,

Offline

#8 2015-02-12 15:29:38

bodo
Member
From: Slovakia
Registered: 2007-10-29
Posts: 8
Website

Re: No journal files were found, for journalctl.

snakeroot wrote:

The issue with this approach is that it will make it very difficult to debug serious, freeze-the-machine, force-to-reboot grade issues, since the journal will be stored only in RAM and thus lost on reboot.

Given your desire to protect your SSD, would it make sense to reset Storage to persistent but reset MaxLevelStore to something pretty high (emerg, alert, crit) from its default level of "debug"? That way you'd have a permanent record on disk of truly bad things, but not the wear and tear of writing every little thing.

Regards,

I understand the drawbacks, but for now It's good enough solution, primary for playing with systemd, it took me 2 years to push myself to "modernize - read as, moving from netcfg to netctl" my ARCH big_smile. I also have HDD disk so in spare time I could create standalone partition for /var/log, hopefully not again in next 2 years big_smile.

Offline

Board footer

Powered by FluxBB