Logrotate in userspace

Ask Fedora
1

I have this configuration for logrotate in /etc/logrotate.d:

/home/usr/ook/borg.log {
    compress
    daily
    delaycompress
    missingok
    notifempty
    rotate 7
    su usr grp
}

When I run sudo logrotate /etc/logrotate.conf --debug, I get this:

rotating pattern: /home/usr/ook/borg.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
switching euid from 0 to 1000 and egid from 0 to 1000 (pid 115458)
considering log /home/usr/ook/borg.log
Creating new state
  Now: 2022-03-21 15:27
  Last rotated at 2022-03-21 15:00
  log does not need rotating (log has already been rotated)
switching euid from 1000 to 0 and egid from 1000 to 0 (pid 115458)

But this is not right. The file was never rotated – there is no borg.log.1 or anything like that.

What am I doing wrong?

2

It seems to be reporting that the file is empty, so it’s not going to rotate an empty file. Try echo test >> /home/usr/ook/borg.log and try logrotate again to test against a log file with content in it.

The other issue is that it hasn’t been a day yet, so you might need to try it again tomorrow with at least some content in the log file.

  Now: 2022-03-21 15:27
  Last rotated at 2022-03-21 15:00
3

Sadly something else must be going on:

√ ; ls -l borg.log
.rw-r--r-- usr usr 32 KB Mon Mar 21 17:00:07 2022  borg.log
√ ; /usr/sbin/logrotate -d /etc/logrotate.conf
[…]
rotating pattern: /home/usr/ook/borg.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
considering log /home/usr/ook/borg.log
  Now: 2022-03-22 08:38
  Last rotated at 2022-03-22 08:00
  log does not need rotating (log has already been rotated)
[…]
√ ; uptime
 08:40:31 up 8 min,  1 user,  load average: 1.43, 1.29, 0.73

So, logrotate thinks that the file was rotated at 08:00 when the machine was not powered up! WOT?

It has not been 24 hours yet so maybe something weird is going on because of that. Hum.

4

You might check that your timezone is correctly set (including DST):

timedatectl show -p Timezone

5 
√ ; timedatectl show -p Timezone && date
Timezone=Europe/London
Tue 22 Mar 18:20:45 GMT 2022

Looks okay to me.

1 Like
6 
√ ; rg borg /var/lib/logrotate/logrotate.status
5:"/home/usr/ook/borg.log" 2022-3-22-8:0:0
√ ; ls -l /var/lib/logrotate/logrotate.status
.rw-r--r-- root root 1.0 KB Tue Mar 22 08:32:24 2022  /var/lib/logrotate/logrotate.status

Now, this might have something to do with it. So, that’s interesting. It might not have been a real time, just logrotate setting a timestamp sometimes in the past

1 Like
7

I’ve run into self inflicted wounds when creating a new logrotate configuration, where one of the earlier times I (unsuccessfully) ran logrotate, the state file indicated that it had already been run that day and so it didn’t run on my second try. Your logrotate.status entry for your /home/usr/ook/borg.log file says it has already been run for that day; you might try either the --force option or just edit the logrotate.status file to remove the borg.log entry.

2 Likes
8

We have progress!

√ ; ls -l borg.log*
.rw-r--r-- usr usr 5.3 KB Wed Mar 23 09:00:07 2022  borg.log
.rw-r--r-- usr usr  90 KB Tue Mar 22 19:00:07 2022  borg.log-20220323
√ ; rg borg /var/lib/logrotate/logrotate.status
5:"/home/usr/ook/borg.log" 2022-3-23-8:31:0

This looks like it is working now… We’ll see tomorrow about compressing the old logs and if that works, all is well.

Not the easiest thing I have ever set up! :wink:

1 Like
9

Today’s results look lile things are working fine.

√ ; ls -l borg.log*
.rw-r--r-- usr usr 5.6 KB Thu Mar 24 09:00:10 2022  borg.log
.rw-r--r-- usr usr 4.3 KB Tue Mar 22 19:00:07 2022  borg.log-20220323.gz
.rw-r--r-- usr usr  38 KB Wed Mar 23 15:00:07 2022  borg.log-20220324

I appear to have done it right then! This was a bumpy ride!

1 Like