Is logrotate supposed to work only in logs inside /var/log?

Question

I currently have a systemd service in a Ubuntu 18.04 machine that redirects the StandardOuput and StandardError to a custom path:

StandardError=file:/opt/my_tests/my.log
StandardOutput=file:/opt/my_test/my.log

But I'd like to add a log rotation and avoid future disk space problems. The way I found to achieve that is using logrotate, because the other solution (journald.conf) requires me to have the log at /var/log/journal/.

After doing some tests with the following file inside /etc/logrotate.d/

/opt/my_tests/my.log {
    missingok
    rotate 10
    maxsize 200k
    copytruncate
    compress
    notifempty
    create 0640 my_user my_user
    dateext
    dateformat -%Y_%m_%d-%H_%M_%S
    postrotate
        echo "A rotation took place"
    endscript
}

I could only have the rotation when running sudo logrotate /etc/logrotate.conf --force independently from size or time flags (such as hourly, daily, or maxsize). Am I missing something here? Would there be another solution to have a log rotation on a custom path?

The output from sudo logrotate -v /etc/logrotate.d/my_conf is:

rotating pattern: /opt/my_tests/my.log  1048576 bytes (10 rotations)
empty log files are not rotated, log files >= 204800 are rotated earlier, old logs are removed
considering log /opt/my_tests/my.log
  Now: 2020-10-23 21:00
  Last rotated at 2020-10-27 18:13
  log needs rotating
rotating log /opt/my_tests/my.log, log->rotateCount is 10
Converted ' -%Y_%m_%d-%H_%M_%S' -> '-%Y_%m_%d-%H_%M_%S'
dateext suffix '-2020_10_23-21_00_30'
glob pattern '-[0-9][0-9][0-9][0-9]_[0-9][0-9]_[0-9][0-9]-[0-9][0-9]_[0-9][0-9]_[0-9][0-9]'
copying /opt/my_tests/my.log to /opt/my_tests/my.log.log-2020_10_23-21_00_30
truncating /opt/my_tests/my.log.log
running postrotate script
A rotation took place
compressing log with: /bin/gzip
removing old log /opt/my_tests/my.log.log-2020_10_26-20_32_32.gz

score 2 · Answer 1 · answered Oct 27 '20 at 10:23

If it performs the rotation with --force, then that implies that your configuration is fine, but logrotate does not believe that the file needs to be rotated at this time.

You can run logrotate -v /etc/logrotate.d/[your conf file] and it should provide a message stating why it is skipping the file. If not, logrotate -d will give additional debugging information that's likely to help pinpoint the cause.

However, looking at your posted configuration, I'm going to guess that the most likely reason is that nothing has actually been written to /opt/my_tests/my.log (i.e., the file has a size of 0), and your config states notifempty, so the file will be skipped if it has size 0.

score 2 · Answer 2 · answered Oct 27 '20 at 10:28

2

logrotate works on any directory you configure, not only /var/logs
your configuration is missing the period when rotation should happen (daily, weekly, ...)
on Ubuntu, logrotate job is triggered by cron. So have a look at /etc/cron.d/ when exactly it would run
depending on your configuration, it could take some days until logrotate actually rotates the file

answered Oct 27 '20 at 10:28

claasz

510
3
10

just saw that my `logrotate` is supposed to run daily, despite some documentation showing that the `daily` update would be ready – ignacio Oct 27 '20 at 11:39
Assuming Ubuntu is the same as Debian on this (which is likely, but I can't verify at the moment), logrotate is run from `/etc/cron.daily`, not from `cron.d`. `/etc/crontab` will tell you what time `cron.daily` tasks are run (6:25 am on Debian). – Dave Sherohman Oct 27 '20 at 13:42

Is logrotate supposed to work only in logs inside /var/log?

2 Answers2