In Ubuntu Server, systemd-journal-flush.service is an early boot script that runs shortly after the root filesystem is mounted. Its sole purpose is to instruct the systemd-journald logging daemon to move all the temporary log data it collected in volatile memory (RAM, usually mounted at /run/log/journal) during the initial boot sequence onto the persistent disk storage (/var/log/journal). While essential for analyzing boot failures on standard servers, in specific highly optimized environments—such as ephemeral, stateless container nodes or Raspberry Pi edge devices running entirely from RAM to prevent SD card wear—flushing the journal to disk is actively detrimental.
This guide explains how to completely disable the systemd-journal-flush service in Ubuntu Server, ensuring that early boot logs remain entirely in volatile memory.
Stop and Mask the Journal Flush Service
To ensure the systemd initialization sequence bypasses the log flushing operation, we must disable the service and mask it so that it cannot be triggered as a dependency by the main journal daemon.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - First, stop the service (though it typically runs once and exits, this clears any active state):
sudo systemctl stop systemd-journal-flush.service - Next, disable the service to prevent it from loading during the normal boot sequence:
sudo systemctl disable systemd-journal-flush.service - To absolutely guarantee that the flush command is never executed by systemd, mask it entirely:
sudo systemctl mask systemd-journal-flush.service
Verify the Boot Optimization
By masking the service, you have effectively symlinked its unit file to /dev/null. The server will now keep early boot logs strictly in /run/log/journal until they rotate out of RAM, completely bypassing the I/O penalty of writing them to persistent storage during startup.
To verify the lockdown is successful, run the following command to check the status of the daemon:
systemctl status systemd-journal-flush.serviceThe output will clearly state that the service is masked. You have successfully optimized your system initialization sequence, eliminating an unnecessary disk I/O operation for environments where persistent boot logging is not required.