How can journald be disabled?

I’ve recently learned that journalctl is occupying a big chunk of my 16GB SD card (Raspberry Pi):

$ journalctl --disk-usage
Archived and active journals take up 312.1M in the file system.  

I don’t feel that journalctl and journald are pulling their weight in my use case for this machine.
It’s an old-ish RPi, and rsyslog is also running. I estimate my need for and use of journalctl is maybe "once in a blue moon". Consequently, I decided I would disable journald – which "feeds" journalctl. I assumed this would be straightforward, using systemctl to stop, or perhaps just disableing the systemd-journald.service so that it would not start on the next boot.

Before pulling the plug, I decided to do somee research. Instead of finding thousands of references that offered "how-to" advice, there were remarkably few results addressing my specific search term: "how to disable journald". Instead, the results mostly offered advice on reducing journald‘s resource consumption. I did find a couple of references that gave me pause:

An old thread in the ArchLinux forum suggested it was not possible to disable journald without repercussions; i.e. "Masking systemd-journald causes all kinds of dependency failures and drops you at an emergency prompt." But this post is now 10 years old…

The systemd-journald.service manual says, "stopping it [systemd-journald.service] is not recommended.". The documentation proceeds from there to discuss namespaces?

I’ve learned that the usual command to prevent systemd units from starting has no effect; i.e. it starts normally:

$ sudo systemctl disable systemd-journald.service
$ sudo reboot 

# ... and after boot & login:

$ systemctl status systemd-journald.service
● systemd-journald.service - Journal Service
     Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Fri 2022-06-03 07:30:29 UTC; 1min 59s ago
TriggeredBy: ● systemd-journald-audit.socket
             ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 134 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 1598)
        CPU: 820ms
     CGroup: /system.slice/systemd-journald.service
             └─134 /lib/systemd/systemd-journald

...
$ 

How can journald be disabled? … or can it be disabled?

If not, why would the systemd developers force this on users? (OK, yeah – asking for an opinion, so forget that part of the question.)

Asked By: Seamus

||

Disabling this service won’t stop your device from functioning but logging will cease obviously. I see no other issues.

Answered By: Artem S. Tashkinov

The reason not to want to eliminate journald when you are using rsyslogd is that rsyslogd can get it’s information from journald, and they play very well together this way.

That is sort of contra some of the Q&A’s linked in comments here. Some observations about this on a current linux system (checked this on Fedora and Debian) which is configured to have journald use only volatile (in memory) storage, with rsyslog writing actual log files:

  • /var/run/log is a directory with one subdirectory, journal. This contains files written to by systemd-journald and read by rsyslogd.
    Note this directory is on a tmpfs partition, hence it counts as in memory volatile storage.
  • /dev/log is a symlink to /run/systemd/journal/dev-log.

The /etc/rsyslog.conf on these systems includes this (which is not the stock rsyslog.conf):

# Input
module (
        load="imjournal"
        ...
)

Fedora and Debian differ in the stock config here; the former does use imjournal as well as imuxsock (userspace socket).1 Debian uses imuxsock and imklog (kernel log), presumably because without imjournal it needs to listen to the kernel itself. I also presume this is a bit anachronistic.

Part of my point here is that completely ripping out journald may not be impossible but it is a bad idea. It is a core component of contemporary systemd based systems. It’s deficit is that it potentially uses much more disk space than rsyslog, but this is easy to configure out by using Storage=volatile and (eg) RuntimeMaxUse=64M in /etc/systemd/journald,

Having rsyslogd fed from journald is a back-end/front-end relationship; rsyslog is great because it provides plain text logging as well as much more fine grained control over what gets logged where and how, while journald provides better integration with system services.


  1. The rsyslog recommendation is to use imuxsock as imuxjournal is less efficient and may suffer from other issues; see also Andrew Henle’s answer about this and comments below.
Answered By: goldilocks

How can journald be disabled?

First, this is what the Rsyslogd documenation says about the imjournal module used to get log messages from systemd’s journal (bolding is original, italics are my emphasis):

Note that this module reads the journal database, what is considered a
relatively performance-intense operation
. As such, the performance of
a configuration utilizing this module may be notably slower than when
using imuxsock
. The journal provides imuxsock with a copy of all
“classical” syslog messages, however, it does not provide structured
data. Only if that structured data is needed, imjournal must be used.
Otherwise, imjournal may simply be replaced by imuxsock, and we highly
suggest doing so
.

We suggest to check out our short presentation on rsyslog journal
integration to learn more details of anticipated use cases.

Warning: Some versions of systemd journal have problems with database corruption, which leads to the journal to return the same
data endlessly in a tight loop. This results in massive message
duplication inside rsyslog probably resulting in a denial-of-service
when the system resources get exhausted. This can be somewhat
mitigated by using proper rate-limiters, but even then there are
spikes of old data which are endlessly repeated. By default,
ratelimiting is activated and permits to process 20,000 messages
within 10 minutes, what should be well enough for most use cases. If
insufficient, use the parameters described below to adjust the
permitted volume. It is strongly recommended to use this plugin only
if there is hard need to do so
.

Do you have a "hard need" to feed "structured data" to rsyslog? And go a lot slower while using significantly more CPU cycles while doing that?

Replacing systemd’s journaling with straight-to-rsyslog is easy:

  1. Edit /etc/rsyslog.conf. Remove all references to imjournal and imuxsock.

  2. Replace the above lines with

    module(load="imuxsock" # provides support for local system logging (e.g. via logger command)
    SysSock.Use="on") # Turn on message reception via local log socket;

  3. Run the following command:

    systemctl stop systemd-journal-flush.service systemd-journald.service systemd-journald-dev-log.socket systemd-journald.socket

  4. Run

    systemctl stop systemd-journal-flush.service systemd-journald.service systemd-journald-dev-log.socket systemd-journald.socket

  5. Run

    systemctl restart rsyslog

  6. Verify messages are appearing in /var/log/messages et al

You may need to tweak some of those commands – especially by disabling more systemd services.

Answered By: Andrew Henle
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.