logrotate installed but not configured

[Dai_trying]

I don't know if this is the same for all versions of sparky or maybe just LXQT (or maybe just a bad installation on my part), but I was doing some tinkering and checking my log files and noticed that my logs are not being rotated. I checked to see if logrotate was installed and it is, so I can only guess that the configuration has been missed or the devs have left it for users to decide what to do.
I am configuring mine now but thought I would post here in the hope that the devs will be reading and may adjust the installation accordingly.

Dai

EDIT:
I think there may be a problem with my installation as cron daily does not seem to be running, I have just manually run

Code Select Expand

sudo /usr/sbin/logrotate /etc/logrotate.conf and noticed the logs got rotated, so for some reason the cron.daily job must be not starting. Any suggestions would be most welcome.

[py-thon]

I am afraid that I don't remember exactly how it works, but maybe this
https://www.digitalocean.com/community/tutorials/how-to-manage-log-files-with-logrotate-on-ubuntu-12-10
can help.

[rollinbeaver]

Hi,

yeah, i'm bitten by a similar bug in all of my about 4 Sparkylinux installations.
There is though a /etc/cron.daily/logrotate which says

Code Select Expand

#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf and /usr/sbin/logrotate does exist, and this /etc/logrotate.conf as well as the entries below /etc/logrotate.d/ look plausible. This looks (to me) correctly configured indeed.
Yet i find no evidence whatsoever that this cron job ever gets done, and my logs just grow.
How to troubleshoot this?
--
regards,
-- that rollinbeaver

[paxmark1]

By logrotate - do you mean the ability to perform "sudo journalctl -b -1"   

If so  "man journald.conf"

either "sudo touch blah"  ## (look it up)

or change in journald.conf  one line

"Storage=persistent"      ##  The  auto switch fails to store the systemd journals UNLESS the appropriate files are present

I have never used logrotate. I did look at man logrotate briefly, and looked at the packages.  It is at 3.8.7-1 in Jessie and 3.8.7-2 in Stretch and Sid.  I do note the BTS bug #734688  - Serious (policy violations or makes package unfit for release) 

DigitalOcean has some really good tutorials on systemd and journald.  The tutorial listed is for Ubuntu and for the October 2012 release.  Peace out. 

edit added sites from Digitalocean
https://www.digitalocean.com/community/tutorials/systemd-essentials-working-with-services-units-and-the-journal

https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

[Dai_trying]

    I have just checked the "BTS bug #734688" and there could be a connection to this although I cannot see any notice in syslog relating to "cron daily". The only notices are to cron.hourly, so I know that one is being run, although I haven't checked (yet) which files are supposed to be rotated to see if they are getting done or not... I think maybe I will have to look at removing all the previous configurations and create my own config files to ensure they get run.
    I am wondering though if it could be because my machines are not always on at the times specified in /etc/crontab (06:25) but I would have thought it would run as soon as possible afterwards...
    I guess more investigation is required and will see if I can resolve it somehow, and post back here if I do.

EDIT:
    I just changed the time in /etc/crontab to 12:00 and waited for the time to pass and cron daily ran, so I would say at this point that the cron jobs are not running unless the system is powered on at the time the cron job is scheduled to run. I would have thought it would run after the time it was scheduled if it had not been run already but it would appear not...

[py-thon]

I would say at this point that the cron jobs are not running unless the system is powered on at the time the cron job is scheduled to run. I would have thought it would run after the time it was scheduled if it had not been run already but it would appear not...

If you want that functionality you have to use anacron instead.
"Unlike cron(8 ), it does not assume that the machine is running continuously.  Hence, it can be used on machines that aren't running 24 hours a day, to control daily, weekly, and monthly jobs that are usually controlled by cron." (from manpages for anacron).

[Dai_trying]

Thanks py-thon, I just checked and anacron is installed (version 2.3-23) I haven't looked for any config files or anything for it yet but will do when I have the spare time. To save me hunting do you have any tips/info on setting up anacron to run correctly?

[py-thon]

To save me hunting do you have any tips/info on setting up anacron to run correctly?

Sorry, I don't remember the details or I would have mentioned them already. It's too long ago.
I had the same problem with logfiles when installing Mint 10 in 2011. With the Sparky installations in 2014 and 2015 everything worked without my interference.

[Dai_trying]

Ok thanks, I'll look into it more when I have time and post back here if I find anything interesting. :)

[Dai_trying]

I think I found what the problem was, when cron.daily/apt runs it has a random delay to prevent everyone from trying to update at the same time and overloading the server, I found that if I reboot the machine after cron.daily has started but before apt has gone beyond the timeout then the timestamp for cron daily has already been updated (before it runs the jobs) and then after reboot it thinks it has already been run.

There are a couple (and probably more) of solutions to this in case anyone else is concerned with it.

1.) rename apt in /etc/cron.daily to zapt and it will run this one last (it appears to do them in alphabetical order) <RECOMMENDED>
2.) remove the delay function (and calls) from the apt script. <NOT recommended (but it's what I have done)>