How do I limit the size of my syslog?

Question

I've got my mom's computer running Ubuntu 12.04 LTS. It's been working just fine but all of the sudden syslog has been filling up. And by filling up I mean I just deleted a /var/log/syslog that was 400GB in size. Yes - Gigabytes.

While I'm sure there was some useful information in there, I'm not sure that 400GB is any kind of information to sift through. And what's really amazing about it is that it happened within a period of 8 hours - I had ran df around noon, and between then and now her drive filled up 30% (from just under 70% to 100%).

What could be causing this and how could I fix it?`

EDIT Looks like the usb is the offender:

Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157829] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157836] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157842] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157849] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157857] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157863] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157870] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157877] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157884] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157891] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use

Answer 1

Limit the size of logrotate

Open the /etc/logrotate.d/rsyslog config file

sudo nano /etc/logrotate.d/rsyslog

The file looks sth. like

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
....
...

Add e.g. size 100k in the parenthesis. Afterwards it should look like:

/var/log/syslog
{
    rotate 7
    size 100k
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Note, that this limits the file size of the rotating files, and not the actual syslog file. Save the file. The next time the logrotate chron job starts, it will limit the size of the rotated logs.

Limit the size of the current syslog

To limit the size of /var/log/syslog, you have to edit the /etc/rsyslog.d/50-default.conf, and set a fixed log size.

Add or modify this setting, by changing the following line in /etc/rsyslog.d/50-default.conf:

.*;auth,authpriv.none       -/var/log/syslog

Here an excerpt of rsyslog manual :

Output channels are defined via an $outchannel directive. It’s syntax is as follows:

$outchannel name,file-name,max-size,action-on-max-size

name is the name of the output channel (not the file), file-name is the file name to be written to, max-size the maximum allowed size and action-on-max-size a command to be issued when the max size is reached. This command always has exactly one parameter. The binary is that part of action-on-max-size before the first space, its parameter is everything behind that space. Please note that max-size is queried BEFORE writing the log message to the file. So be sure to set this limit reasonably low so that any message might fit. For the current release, setting it 1k lower than you expected is helpful. The max-size must always be specified in bytes - there are no special symbols (like 1k, 1m,…) at this point of development. Keep in mind that $outchannel just defines a channel with “name”. It does not activate it. To do so, you must use a selector line (see below). That selector line includes the channel name plus an $ sign in front of it. A sample might be: . :omfile:$mychannel In its current form, output channels primarily provide the ability to size-limit an output file. To do so, specify a maximum size. When this size is reached, rsyslogd will execute the action-on-max-size command and then reopen the file and retry. The command should be something like a log rotation script or a similar thing.

If there is no action-on-max-size command or the command did not resolve the situation, the file is closed and never reopened by rsyslogd (except, of course, by huping it). This logic was integrated when we first experienced severe issues with files larger 2gb, which could lead to rsyslogd dumping core. In such cases, it is more appropriate to stop writing to a single file. Meanwhile, rsyslogd has been fixed to support files larger 2gb, but obviously only on file systems and operating system versions that do so. So it can still make sense to enforce a 2gb file size limit.

Here the max-size is 1MB, place this line before the *.*; ... line

$outchannel mysyslog,/var/log/syslog,1048576

and change the *.*; ... line into

*.*;auth,authpriv.none  :omfile:$mysyslog

Restart rsyslogd ether with

sudo systemctl restart  rsyslog.service

or

sudo service rsyslog restart

To look at the rsyslog status type

systemctl status rsyslog.service  

Answer 2

You should find out what is causing the large amount of messages, as if you fix this issue then you fix the large log file.

However, until then you can put in a log rotation base on one of the below.

• time ( eg. rotate every day )
• size ( eg. rotate when the file reaches 10mb )

This will already be setup on the system by default: /etc/logrotate.d/rsyslog

 /var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
            reload rsyslog >/dev/null 2>&1 || true
    endscript
 }

From this you can see that it will rotate he /var/log/syslog file daily and keep 7 copies of the rotated file.

You can change this to be rotate on a size limit, say 1mb or reduce how many copies it stores.

Warning: This will not fix the root cause of your issue, however it will buy you some time as it will stop the file system from filling up.

• Source: /etc/logrotate.d/rsyslog
• Source: man logrotate

Answer 3

I had the same problem with a Lexmark Pro915 for two weeks. I did two things, and it now works fine. I reinstalled the driver. (Don't think this was what helped.) I took out the USB extension I was using which made the total length almost 15' long and which might not have been entirely compatible. I suspect that the Lexmark driver for Linux systems might be detecting a poor, or poorly timed, signal and wanting to tell you about it 10 billion times a day. Try improving your connection somehow.

Logrotate and similar solutions didn't help me. Kern.log and syslog together were logging more than 1TB a day! Logrotate might help if you could set it to run every twelve minutes.