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 [Journal] Storage=persistent Compress=yes SystemMaxUse=100M SystemMaxFileSize=20M machineC, however, uses no persistence and uses a purely volatile journal (with syslog): [root@comptroller systemd]# egrep -Ev '^[[:space:]]*(#|$)' journald.conf [Journal] Storage=volatile Seal=no SystemMaxUse=50M RuntimeMaxUse=50M ForwardToSyslog=yes 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 )
this issue continues to persist on linux 4.0.4.
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.
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.
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.
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.