On my raspberry I really don't need crons and pam logging and I want to have less i/o to make the SD card life a little longer..

I have already removed cron with the second line cron.none, I'm currently testing the authpriv.none

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none,cron.none             -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

Basically, all I want to log is fatals, hardware stuff, kernel/dmesg, and failed logins

What else can I improve?

  • 4
    I cannot comment yet so I write this here: @goldilocks is wrong :( I managed to kill multiple SD cards in multiple rasperries. It's not hard at all. (No they were not busy database servers.) The problem is that 1 MB is not 1 MB write. To modify a byte in a file the flash memory has to modify an entire page. It's done probably with a copy to a new page (wear leveling). Also writing to a file is not just 1 write, because the file system (file write time, file size) is also updated. Before a bit can be flipped in a certain direction the entire flash erase block has to be erased (reset all bytes t Sep 28, 2015 at 8:42

2 Answers 2


This is not the answer you are looking for, because I am going to try and dissuade you from this (which is actually the only rational answer).

On my raspberry I really don't need crons and pam logging and I want to have less i/o to make the SD card life a little longer..

If you think cron is truly doing excessive logging, then you should consider what cron is doing and how often, and tweak that. Point being, if you don't care much about what it is doing, then why is it doing it?

WRT SD cards, logging is not significant enough to worry about. As in: totally insignificant, you are wasting your time thinking about it. SD cards use wear leveling to help preserve themselves: they don't suffer the effects of fragmentation (i.e. fragmentation is irrelevant to performance), and when you write to disk, the data is written to the least used part of the card, where ever that is. This transcends partition boundaries, so if you have a 2GB partition on a 16GB card, the partition is not limited to a 2GB wide block of physical addresses: it is a dynamic 2GB whose physical addresses will be a non-contiguous, ever-changing list encompassing the entire card.

If your system writes a MB of logs a day (you can check this by sending a copy of everything to one file, which is often what /var/log/syslog is), and you have a 4 GB card, it will take 4000 days before such a cycle has written to the entire card just once. The actual lifespan of an SD card might be as much as 100,000 write cycles [but see comments]. So all that logging will wear the card out in 4000 * 100000 / 365 =

~ 1 million years

Do you see now why reducing logging by 25%, or 50%, or even 99%, will be completely irrelevant? Even if the card has an incredibly bad lifespan in terms of write cycles -- say, 100 -- you will still get centuries of logging out of it. For a more in-depth test demonstration of this principle, see here.

Basically, all I want to log is fatals, hardware stuff, kernel/dmesg, and failed logins

Unless you enable "debug" level logging, by far the thing that will write the most to your logs is when something has gone really wrong, and generally those are going to go in as high priority unless you just disable logging entirely. For example, I doubt under normal circumstances that your pi, using the default raspbian config, writes 1 MB a day of logs, even if it is on 24/7. Let's round it up to that. Now say a defective kernel module writes the same 100 byte "emergency" panic message 50 times per second to syslog on an unattended system for one week: 100 * 50 * 60 * 60 * 24 * 7 = ~ 30 MB. Consider that in relation to the aforementioned lifetime of the card, and the fact that you probably want to get the message.

Logging that haywire is very unusual, BTW. Logging is good. The logs are your friends. If you want to tinker with the rsyslog configuration, your time will be better spend adding more, not less.

  • nice explanation
    – Daniel W.
    Jul 30, 2013 at 13:22
  • 6
    Umm, not quite. 100,000 cycles is going to be expensive SLC flash; MLC flash is more like 1,000–3,000. You can see actual test data here, which shows its around 1,500. Second, even if you only write one byte, it will actually write at least one sector—possibly more, as the flash eraseblock is much larger, and wear leveling amplifies writes further. When you put those together, wearing out the card is doable.
    – derobert
    Jul 30, 2013 at 15:35
  • 1
    ... though still probably not from normal logging.
    – derobert
    Jul 30, 2013 at 15:41
  • @derobert : A million years is admittedly ridiculous, but even if you reduce that by a factor of 100 (or 1000 or 10,000, or 100,000), it's still long enough. I have no doubt you can wear an SD card out if you, eg. run a busy database server off it, but 1 MB / 24 hours is just plain nothing. I don't think there is a point in worrying about how you use the card beyond being aware of what the limitations of the media are (e.g. don't use them for a busy database server unless there is no other choice).
    – goldilocks
    Jul 31, 2013 at 9:25
  • 2
    @goldilocks I agree with your conclusion that normal logging isn't a real issue (unless you need a really long life from the card) but being off by three to four orders of magnitude is not OK. Suggest you edit your answer and use the right numbers.
    – derobert
    Aug 2, 2013 at 15:03

Although you mention rsyslogd specifically (and it has been over 3 years since you've asked the question), I feel that another option should be mentioned here: busybox-syslogd. It can (and does by default in raspbian) store the log messages in memory, to be retrieved by logread, without writing anything to the disk at all. It's the perfect solution for a read-only mounted disk!

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .