How do I permanently disable all logs that appear in /var/log/? I tried "service rsyslog stop", "systemctl disable rsyslog" but it still logs stuff because I type "sudo journalctl --vacuum-time=1s" and it deletes 5.7M of logs each time I reboot.

  • 1
    why do you need to disable logging?
    – jsotola
    Commented Mar 18, 2020 at 17:54
  • would certainly not recommend disabling all logging, if you feel like the logs are taking up too much space, adjust logrotate config files to do so. But in their default state, they are already going to be rotating logs out as they become "old" so usually there is nothing you need to do, your filesystem is not going to fill up due to this logging.
    – Chad G
    Commented Mar 18, 2020 at 21:33
  • 5
    @jsotola, disabling constant logging will increase the life of my SD card, as they have finite write cycles.
    – user96931
    Commented Mar 18, 2020 at 22:05

2 Answers 2


Journald does potentially consume a lot of disk space compared to the traditional text based logging done by rsyslog. In addition, since both are enabled by default in Raspbian, there is the implication that you will end up with redundant waste.

Fortunately, that's not quite how it is configured; from /usr/share/doc/systemd/README.Debian:

To enable persistent logging, create /var/log/journal:

mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal

systemd will make the journal files owned by the "systemd-journal" group and add an ACL for read permissions for users in the "adm" group.

This works because journald's default Storage mode is auto, meaning the logs will be kept in memory unless /var/log/journal or /run/log/journal exists1 -- and they do not in the base image [Later: They do in current versions]. You will find these settings (Storage, etc.) in /etc/systemd/journald.conf, and an explanation of them in man journald.conf; note that all of them are commented out, so journald policy defaults, explained in the man page, are used.

This means the rsyslog text records are unique. That README (which is worth a browse) also notes that "If you enable persistent logging, consider uninstalling rsyslog or any other system-log-daemon, to avoid logging everything twice."

Limiting text files

Storage of the text logs, created by rsyslog, can be controlled with logrotate; see man logrotate and man logrotate.conf (there's also no shortage of material online about it). This rolls the files over, potentially compresses them, and discards based on volume and/or age. Traditionally logrotate is executed by cron, but current Raspbian does it via a systemd timer (see /etc/systemd/system/timers.target.wants/logrotate.timer; check that it really is enabled with systemctl status logrotate.timer).

Limiting journald

Journald has a conf file, /etc/systemd/journald.conf. All the settings there are (as mentioned above) commented out, but it can be configured to guarantee that no disk space at all is used regardless of whether /var/log/journal exists. This is probably not desirable unless rsyslog, which writes the text files, is also running, so that there will at least potentially be some record left if the system crashes, if you want to compare current state to a previous point in time, etc.

To restrain journald, add this under [Journal] in the conf file:


This means the logs will be kept in memory with a 64 MB limit; entries are then discarded based on age (it may be more complicated than that, but it is mostly age). You can play around to see how far back 64 MB will get you, but it is probably at least a couple of days. RuntimeMaxUse applies only to logs in memory, but there is a parallel parameter for the "on disk" persistent storage, SystemMaxUse.

Putting it together

So, that outlines two basic methodologies for logging with a size/time constrained permanent record:

  1. Disable rsyslog, create /var/log/journal (if it doesn't exist already), set SystemMaxUse in /etc/systemd/journald.conf.
  2. Set Storage=volatile in jounrnald.conf, leave rsyslog alone, and tailor /etc/logrotate.conf(and /etc/logrotate.d/*, from which it sources) to your liking.

The latter is the default scenario on Raspbian, but the logrotate configuration does not set any size constraints, only time based ones (to do that, see the doc references for logrotate above).

  1. /run/log/journal would actually just be in memory too, as /run is a tmpfs filesystem. But it would give you additional access.
  • B.t.w., the journal is only kept in memory by default. Because I don't need older logs I just do apt --autoremove purge rsyslog.
    – Ingo
    Commented Mar 20, 2020 at 16:53
  • @Ingo That journald.conf tweak is something I've been doing whenever I set a new system up from the start, so if the default (on Raspbian) is already volatile then I would not have noticed (it certainly wasn't that when I first figured this out, but that would have been on a big fedora box). However: Since there's no configuration done on Raspbian (journald.conf is all comments), I think the default (as per man journald.conf) is probably auto, meaning it will write to disk if a /[var|run]/log/journal directory exists, otherwise it is in memory...
    – goldilocks
    Commented Mar 20, 2020 at 17:09
  • ... and the default RuntimeMaxUse is 10% of total RAM. /[var|run]/log/journal don't exist in the Raspbian base image, so you are right.
    – goldilocks
    Commented Mar 20, 2020 at 17:10
  • Do you know /usr/share/doc/systemd/README.Debian?
    – Ingo
    Commented Mar 20, 2020 at 22:33
  • I did not (almost everything in /usr/share/doc/ is just changelogs and such). But it certainly confirms this -- thank you, I will edit that in here.
    – goldilocks
    Commented Mar 21, 2020 at 13:42

If your intent is to reduce the potential for SD card corruption, then you should look at Adafruits tutorial for a "Read Only Raspberry Pi" -
https://www.raspberrypi.org/blog/adafruits-read-only/ It is not perfect, but it will stop all logging and seems to survive most inadvertent power failures.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.