11

Our log file /var/log/syslog does not seem to be rotating, even though the logrotate config /etc/logrotate.d/rsyslog exists:

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

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
    rotate 4
    weekly
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        reload rsyslog >/dev/null 2>&1 || true
    endscript
}

See, the syslog log file is 600M with no old files or compressed.

-rw-r-----  1 syslog   adm    600M Nov  9 20:30 syslog
Justin
  • 531
  • The rotation is based on logfile age, not size. Is it a day old yet? – muru Nov 09 '15 at 20:42
  • Yes, server has been running for over 30 days. Actually, it appears that logrotate is not working at all, because there are no compressed or backup log files in /var/log. Anywhere to log for issues? – Justin Nov 09 '15 at 20:50
  • 2
    What happens if you run logrotate yourself? sudo logrotate -d /etc/logrotate.conf - the -d enables debug mode. – muru Nov 09 '15 at 20:52
  • Running as ubuntu I see error: skipping "/var/log/syslog" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.. The permissions on /var/log are 775. – Justin Nov 09 '15 at 20:56
  • In my case logrotate did nothing, because there was already no space left on the device :) – shitpoet Jun 16 '24 at 10:08

5 Answers5

17

I found the problem, somehow su directive got removed from /etc/logrotate.conf, so needed to add:

# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog
Justin
  • 531
2

I used the same su approach mentioned by @Justin, except I had to add it to he service-specific logrotate config file (instead of the global logrotate config file):

  1. Determine the su user/group to use from the global logrotate config file

    grep 'su ' "/etc/logrotate.conf"

  2. Edit rsyslog logrotate config

    vi "/etc/logrotate.d/rsyslog"

  3. Prepend the su line (from step 1) to the top of the file:

    su root syslog

  4. Test for errors

    logrotate --debug --force /etc/logrotate.d/rsyslog 2>&1 | grep -i cron

bvargo
  • 616
Cavallo
  • 21
1

I had a similar problem and it seems to have been caused by some kind of incompatibility between the logrotate configuration and the new systemd replacement for sysv/init.d

I had to edit the /etc/logrotate.d/rsyslog and replace

invoke-rc.d rsyslog rotate > /dev/null

with

systemctl kill -s HUP --kill-who=main rsyslog.service

the previous line looked like it was working, and said so, but did not manage to get rsyslog to reopen its logfiles.

damadam
  • 2,883
Samuel Åslund
  • 239
1

I'm answering 8-years later as this is still a top result in search engines.

(1) As @Justin mentions, the first solution is to ensure your /etc/logrotate.conf is performing and su to the same permissions as the log files:

su root syslog

(2) If you are running inside a container, you may need to update your logrotate.service to disable certain kernel protections (this is a common reason for namespace failures, as a container doesn't have permission to access the kernel in a way to enable these features). Although you can enable nesting on your container, this may cause other user-space issues. To simply disable the kernel protections inside the container:

sed -ie 's/^ProtectKernel/\#ProtectKernel/g' /lib/systemd/system/logrotate.service
systemctl daemon-reload

(3) If the above steps fail, some systems may need "/var/log" explicitly added to the service file:

echo "ReadWritePaths=/var/log" >> /lib/systemd/system/logrotate.service
systemctl daemon-reload

(4) If the above steps fail, you may need to disable other system protections in /lib/systemd/system/logrotate.service, which may be any of the following:

LockPersonality=true
MemoryDenyWriteExecute=true
PrivateDevices=true
PrivateTmp=true
ProtectClock=true
ProtectControlGroups=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=full
RestrictNamespaces=true
RestrictRealtime=true

Each of which may be set to "true", and the lines may be changed to "false" or commented-out. It would be wise to go through one-by-one to see which line(s) are causing the issue on your system.

cegfault
  • 261
0

Based on Samuel's comment, modified /usr/lib/rsyslog/rsyslog-rotate

#!/bin/sh

if [ -d /run/systemd/system ]; then
    systemctl kill -s HUP --kill-who=main rsyslog.service
else
    invoke-rc.d rsyslog rotate > /dev/null
fi
Matteljay
  • 101