Bug 90268

Summary: (tmpfiles,journald) systemd 219 + linux 4.0.x = journal failing to append on boot
Product: systemd Reporter: brent s. <brent.saner>
Component: generalAssignee: systemd-bugs
Status: RESOLVED WORKSFORME QA Contact: systemd-bugs
Severity: critical    
Priority: high CC: brent.saner
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
URL: https://bugs.archlinux.org/task/44799
i915 platform: i915 features:

Description brent s. 2015-05-01 14:30:51 UTC
in some cases (i can't seem to narrow down which yet), systemd fails to create /run/log/journal. This then causes further failure of journald to fail to both:

-append to the volatile journal
-append to the persistent journal (if one exists)- no flushes, as the volatile journal is not appended

from what i understand, the volatile journal does not exist because it normally is written to /run/log/journal. on boot, the entries of /run/log/journal are copied over to the persistent journal in /var/log/journal/ (if persistence is enabled) (is this correct?).

this is occurring on fully updated/patched Arch Linux, x86_64.
this behaviour does not exist on kernel 3.19.3.

of three machines with systemd, i note the following:

machineA (desktop): does not create /run/log/journal; no new journal entries are created.

machineB (laptop): does not create /run/log/journal; HOWEVER, new journal entries SEEM to be appended/created.

machineC (firewall box): /run/log/journal IS created; new journal entries are added.

machineA and machineB share the exact same /etc/systemd/journald.conf (with no syslog):
[bts@workhorse systemd]$ egrep -Ev '^[[:space:]]*(#|$)' journald.conf 

machineC, however, uses no persistence and uses a purely volatile journal (with syslog):
[root@comptroller systemd]# egrep -Ev '^[[:space:]]*(#|$)' journald.conf 

as a temporary workaround, it seems that "systemctl restart systemd-journald" on the affected machine (machineA) seems to allow new journal entries. however, /run/log/journal is still not created during the restart.

let me know what logs/output/etc. you wish to see.

(cross-linking for reference: https://bugs.archlinux.org/task/44799 )
Comment 1 brent s. 2015-05-20 20:34:58 UTC
this issue continues to persist on linux 4.0.4.
Comment 2 brent s. 2015-05-20 20:36:07 UTC
increasing severity/importance due to this being a huge failure- i have no way of getting logging running reliably on this box and there has been no response.
Comment 3 brent s. 2015-05-28 05:47:37 UTC
as an update, this appears to occur under the following conditions:

-/var is mounted as a bindmount,
-on another disk from /

not sure which is the cause. my guess is the first, but i do this to avoid unnecessary writes to the SSD (which / resides on).

please fix.
Comment 4 raoul 2016-12-17 10:40:43 UTC
I have the same exact problem (with /var/log mounted as tmpfs to avoid unnecessary writes to the SSD disk). Apparently this issue has never been fixed.
Comment 5 Lennart Poettering 2017-10-27 18:04:27 UTC
The relevant code has been reworked substantially in more current systemd version. If this continues to be a problem with 235, please open a new issue on github, and let's continue the discussion there. Thank you.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.