1

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 

2 Answers 2

3
  • 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
2
  • just saw that my logrotate is supposed to run daily, despite some documentation showing that the daily update would be ready Commented Oct 27, 2020 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). Commented Oct 27, 2020 at 13:42
2

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.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.