Logs not rotated

UNIX for Beginners Q & A
1

I'm fairly new to this...

System: Kali Linux - based on Debian (Stretch)
uname -a : Linux kali 4.18.0-kali3-amd64 #1 SMP Debian 4.18.20-2kali2 (2018-11-30) x86_64 GNU/Linux

I noticed that the space on my root partition was continuously shrinking even though I didn't do much on the machine and it wasn't even running continuously. Then I tested a script with a lot of calls to sudo in it and noticed that var/log/auth.log was getting rather large - understandable because of the sudo calls. I took a closer look at /var/log and it looks like there haven't been any log rotations since the end of August.

According to crontab they should be rotated every day. (I'm not sure what role anacron plays here currently which may be responsible for this kind of task if the machine isn't running 24/7.)

I took a look at /etc/cron.daily/logrotate (see below) and I don't understand the purpose of the test for the existence of /run/systemd/system and the exit if it exists. The directory is empty but it exists - so unless it disappears periodically the rest of the script will never execute.

I then executed the command /usr/sbin/logrotate /etc/logrotate.conf (at the end of the script) by hand and the logs were rotated.

root@kali:/var/log# ll auth*
-rw-r----- 1 root adm      2013 Dec 12 16:25 auth.log
-rw-r----- 1 root adm 264686726 Dec 12 15:15 auth.log.1
-rw-r----- 1 root adm      1107 Aug 28 05:39 auth.log.2.gz
-rw-r----- 1 root adm      2342 Aug  5 21:10 auth.log.3.gz
-rw-r----- 1 root adm      4927 Jul 30 08:39 auth.log.4.gz

Okay, I may be on a completely wrong track here and would benefit from a hint in the right direction.

Here the code of /etc/cron.daily/logrotate:

#!/bin/sh

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi

# this cronjob persists removals (but not purges)
if [ ! -x /usr/sbin/logrotate ]; then
    exit 0
fi

/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit $EXITVALUE

Thanks.

2

Is cron running? Check with service cron status or service crond status . Alternatively look at cron entries in system log files. Does it show up in ps ? Any error messages?

3

I suppose you could run this as root and see what happens. Try with the debug/trace turned on:-

bash -x /etc/cron.daily/logrotate

What is in /etc/cron.daily/logrotate? It may be working as designed, but there are no rules being activated.

It will probably be something trivial, but infuriating. I've had 'fun' with them myself.

Kind regards,
Robin

4

Looks like it does:

root@kali:~# service cron status
 cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-12-13 01:54:32 CST; 7h left
     Docs: man:cron(8)
 Main PID: 552 (cron)
    Tasks: 1 (limit: 4915)
   Memory: 1.1M
   CGroup: /system.slice/cron.service
           552 /usr/sbin/cron -f

Dec 13 01:54:32 kali systemd[1]: Started Regular background program processing daemon.
Dec 13 01:54:32 kali cron[552]: (CRON) INFO (pidfile fd = 3)
Dec 13 01:54:32 kali cron[552]: (CRON) INFO (Running @reboot jobs)
Dec 13 01:55:01 kali CRON[949]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 13 01:55:01 kali CRON[950]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Dec 13 01:55:01 kali CRON[949]: pam_unix(cron:session): session closed for user root

--- Post updated at 10:10 AM ---

It does what I expected. The directory /run/systemd/system exists and hence:

root@kali:/etc/cron.daily# bash -x logrotate
+ '[' -d /run/systemd/system ']'
+ exit 0

I run another Debian based distribution (Raspbian) on a Raspberry Pi. That one has a shorter version of /etc/cron.daily/logrotate. It doesn't test for existence of /run/systemd/system. No problems over there:

(transcribed by hand):

#!/bin/sh


test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf
5

grep for "rotate" in the system logs I find

Dec 12 08:30:08 RudisPC systemd[1]: Started Rotate log files.

What do you?

Hoppla - cross posted. Looks like it thinks you have cron running in parallel to systemd timer. Need to read deeper.

6

Do you mean /var/log/syslog?

root@kali:/var/log# cat syslog | grep "rotate"
root@kali:/var/log#

Nothing there.

7

grep and most other utilities do not need cat's help to read a file.

grep "rotate" filename
8

Yes i know but it's the way I think... there's this file - cat it - and that's what I want from it... grep that.
Flows like that, kind of.
Maybe I should change that.

9

You could also write it <inputfile grep "string"

10

Wow. Never thought of that.
Looks kind of eccentric - but saves three characters compared to cat. Plus two for the pipe.

When it comes to saving screen space

also helps.

--- Post updated at 05:18 PM ---

About the actual topic:
Absent additional input I plan to comment out the test for run/systemd/system and observe the situation for some time.

11

You can manually run

logrotate -d /etc/logrotate.conf

and it tells what it would do - without doing anything.

12

You could also check the directory and remove / rename for a test.

13

What if I restart the machine? Being in the /run directory won't it be recreated as 'system' when the system comes up again?

14

"for a test" doesn't necessarily include a reboot...

15

I tried that. Concerning the auth.log it says:

considering log /var/log/auth.log
  Now: 2018-12-13 06:15
  Last rotated at 2018-12-12 15:15
  log does not need rotating (log has been rotated at 2018-12-12 15:15, that is not week ago yet)

But that was yesterday when I set off the logrotate command manually.

The problem appears to be the test for -d /run/systemd/system. If the directory exists the script exits right away. (See my original post.)

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
     exit 0 
fi

I don't understand how it could detect the system timer by checking for the existence of that directory.

--- Post updated at 10:57 PM ---

The machine doesn't run 24/7. So unless I perform a test right after renaming the directory (which one?) it will be recreated as 'system' after a reboot. (I just rebooted and checked.)

17

Of course you can comment out the check for systemd in /etc/cron.daily/logrotate.
But an update of the respective package might re-instate the original file.

The better alternative is to look what systemd is supposed to do:
Look if there is anything with "log" or "rotat" in

find /usr/lib/systemd/ /lib/systemd/ -type f -name "*.timer" \( -name "*log*" -o -name "*rotat*" \) -print

?
Then also look for the corresponding .service file!