Hi, where is the code that starts logrotate in OpenSUSE 13.2? I can’t find it anywhere. It’s not started by cron in /etc/cron.daily, /etc/cron.weekly, /etc/crontab, /etc/cron.d, or any other place associated with cron that I can find.
Thanks!
13.2 uses a different systemd logging system. If you need the old logs you will need to install one of the older logging systems
logrotate is a systemd service in 13.2 (/usr/lib/systemd/system/logrotate.service) and it is run periodically by a systemd timer (not cron).
Have a look at /usr/lib/systemd/system/logrotate.timer and “man systemd.timer”.
Hi
Probably /etc/logrotated.conf and the files in /etc/logrotate.d/ along with the static systemd service logrotate.service 
The status can be seen via /var/lib/logrotate.status
@gogalthorp: Yes, I know that. Even if I wasn’t running syslog-ng, there are still services that write their own logs.
@wolfi323: Thank you! I was going crazy, and obviously I haven’t fully synced with all of the new features in systemd.
On 2014-12-29 18:16, wolfi323 wrote:
> Have a look at /usr/lib/systemd/system/logrotate.timer and “man
> systemd.timer”.
oS-13-2:~ # rpm -qf /usr/lib/systemd/system/logrotate.timer
logrotate-3.8.7-6.1.2.x86_64
oS-13-2:~ #
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
This is a severe bug, imo. The above answers are somewhat correct, but a better explanation of the problem & solution is under this bug report:
https://bugzilla.novell.com/show_bug.cgi?id=913421
(“logrotate not running after update from 13.1 to 13.2”)
Posted for those seeking help in the future, because it seems a lot of people suffer from this problem (but rarely notice, because who checks log sizes until it’s too late?)
I have been tracking the referenced bug report and see no solutions for my problem - I sleep my machine most every night, so an “OnBoot” derived timer won’t help.
Until
Comment 4:
That would be solved by Persistent=true in the logrotate.timer.
(it triggers immediately if it would run when it was inactive)
Unfortunately the systemd in 13.2 doesn't support that.
Gets resolved (works again), it seems my best options are to change the timer to run daily at an hour the computer is likely to be on.
Or, set a reminder for myself and run logratate manually, I suppose.
Any better thoughts?
It’s running on my wife’s 13.2 box – systemctl list-timers shows it. And I know I didn’t start it…
Thanks for the observations, susesteve.
logrotate.timer is running on my machine as well, but logs are not being rotated because I am seldom running at 12AM (midnight when the timer is set to run (the default - daily).
My observations, and understanding of the issue in the bug report, is that unlike cron (13.1 and prior), is that logrotate will only be run if the system is UP when. the timer is set to be triggered (exactly, plus minus accuracy). cron timers would catchup if a timer was set for 12:00AM but the system was DOWN (e.g. suspended)
The terminology is that Persistent=true is not functional with the 13.2 systemd setup.
Are logs on your wife’s machine being rotated? By default, they should rotate weekly.
Is her computer ‘UP’ at 12AM?
Here’s the specific output (minus the column headers, etc - I ran the command at 5 PM local):
aristotle:~ # systemctl list-timers
Fri 2015-04-17 00:00:00 MDT 7h left logrotate.timer logrotate.service
It’s going to run at midnight. And we do keep our systems on all the time. I’ll check and see if the logs are in fact rotated.
The easiest way to tell would be
# ls -l /var/log/mess*
-rw-r----- 1 root root 677287 Apr 16 18:15 /var/log/messages
-rw-r----- 1 root root 257364 Oct 30 20:15 /var/log/messages-20141030.xz
-rw-r----- 1 root root 250600 Nov 10 19:15 /var/log/messages-20141110.xz
-rw-r----- 1 root root 229560 Nov 15 20:00 /var/log/messages-20141115.xz
-rw-r----- 1 root root 535604 Apr 5 11:23 /var/log/messages-20150405.xz
You can see rotation on my system until mid November, likely when I upgraded.
I believe the April 5, 2015 is when I manually ran logrotate while hacking about following the bug description.
You should see, on your wife’s system a rotated messages.xz, no older than one week, assuming your did not change the defaults (rotate weekly).
It will be interesting to see, thanks for the info
Hmm. /var/log/messages no longer exists on default installation of 13.2.
See this thread:
/var/log/messages missing
Interesting find - I had not seen that the default install had changed.
I upgraded from 13.1 (and 12.3, 12.2, …) which likely explains my environment.
I’ll assume you did a clean 13.2 install.
And I’ll further assume that part of this disconnect with logrotate and systemd is that in a ‘clean’ systemd system, there are no logs to rotate.
Hmmmmmm
And now that I look, I see systemd journaling in /var/log/journal going back to 2013!
I guess I need to read up a bunch on how to use and manage these as well.
That’s not completely true.
cron itself does not catchup if the system is not running at the specified time. I.e. if you create a cronjob that should run on April the 20th on 0:00, and the system is not up at that time, the job will never run.
That’s what anachron is for.
But (open)SUSE contains a script (that’s started by cron every 15 minutes) to run jobs in /etc/cron.d/, /etc/cron.daily/ and /etc/cron.weekly.
This script takes care that those jobs are run even if the system is not up at the time they should run.
But that is an (open)SUSE specific thing. That script can be configured in /etc/sysconfig/cron btw.
No.
Apparently there is a bug that doesn’t enable the timer automatically when installing 13.2 or upgrading (upto 13.1 logrotate was called by a cronjob, not a systemd timer).
And btw, there are other logs to be rotated as well, not just /var/log/messages/. Those other logs exist in a “‘clean’ systemd system” as well.
E.g. /var/log/zypper.log or the mysql logs.
If you want to disable systemd’s on-disk journal, just delete the folder /var/log/journal/. If you want to disable the logging to /var/log/messages and other text files, uninstall rsyslog.
AFAIK, systemd’s journal is “rotated” automatically by systemd-journald (or rather it is compressed anyway, so no need to compress it regularily like logrotate does), or you can even specify a maximum size in /etc/systemd/journald.conf, or you can even specify a maximum size there.
See also “man journald.conf”.
wolfi323 https://forums.opensuse.org/images/misc/quote_icon.png Originally Posted by cmcgrath5035 https://forums.opensuse.org/images/buttons/viewpost-right.png](https://forums.opensuse.org/showthread.php?p=2705246#post2705246)
TMy observations, and understanding of the issue in the bug report, is that unlike cron (13.1 and prior), is that logrotate will only be run if the system is UP when. the timer is set to be triggered (exactly, plus minus accuracy). cron timers would catchup if a timer was set for 12:00AM but the system was DOWN (e.g. suspended)That’s not completely true.
cron itself does not catchup if the system is not running at the specified time. I.e. if you create a cronjob that should run on April the 20th on 0:00, and the system is not up at that time, the job will never run.
That’s what anachron is for.
But (open)SUSE contains a script (that’s started by cron every 15 minutes) to run jobs in /etc/cron.d/, /etc/cron.daily/ and /etc/cron.weekly.
This script takes care that those jobs are run even if the system is not up at the time they should run.
But that is an (open)SUSE specific thing. That script can be configured in /etc/sysconfig/cron btw.
OK, thanks. I have been using openSUSE almost exclusively for so long I thought the “catch up” behavior was Linux, not openSUSE Linux.
https://forums.opensuse.org/images/misc/quote_icon.png Originally Posted by **cmcgrath5035** https://forums.opensuse.org/images/buttons/viewpost-right.png](https://forums.opensuse.org/showthread.php?p=2705306#post2705306) IAnd I'll further assume that part of this disconnect with logrotate and systemd is that in a 'clean' systemd system, there are no logs to rotate. No.Apparently there is a bug that doesn’t enable the timer automatically when installing 13.2 or upgrading (upto 13.1 logrotate was called by a cronjob, not a systemd timer).
And btw, there are other logs to be rotated as well, not just /var/log/messages/. Those other logs exist in a “‘clean’ systemd system” as well.
E.g. /var/log/zypper.log or the mysql logs.
Yes, I agree, so will clarify that there is both a bug (timer not enabled) and a (lack of) feature that logrotate will not be run if the computer is not UP when the timer is scheduled. So following the recommended work around at the top of this thread (and in the bug report) to enable the timer does not really fix all the issues unless A. computer is UP 7x24 or B. You change the logrotate timer time.
I believe this is because openSUSE specific feature you mention above that does ‘catch-ups’ for missed cron jobs does not work now that logrotate is initiated by logrotate-timer.
I am viewing this whole situation as a wake up call to learn a bit more about ALL of systemd and migrate to using journalctl for my log reading needs once I understand how to use it.
First up is to get the accumulated size of all these logs under better control.
Yes.
Although I had a look at the logrotate.timer unit file now, and it does contain this:
AccuracySec=12h
According to “man systemd.timer”:
Note that timers do not necessarily expire at the precise time
configured with this setting, as it is subject to the AccuracySec=
setting below.
So as I understand it, with AccuracySec=12h the system does not have to be up precisely at 0:00, as the timer can fire in a range of +/- 12hrs, i.e. practically at a random time each day.
I’m not sure about the exact behaviour though.
So following the recommended work around at the top of this thread (and in the bug report) to enable the timer does not really fix all the issues unless A. computer is UP 7x24 or B. You change the logrotate timer time.
A third option would be to use a so-called “monotonic” timer.
This does not specify a specific time, but how long (in system run time) after some specific event it should be run. It can e.g. be relative to booting or to when it was last started, so it would be possible to say “run 15 minutes after the system has been booted, and then every time the system has been running for 12 hours”.
See also “man systemd.timer” if you are interested.
Btw, if you intend to change some systemd unit files, you should copy them to /etc/systemd/system/ first, so that your changes don’t get lost when installing updates.
There’s also a way to only override certain options of a systemd unit.
I believe this is because openSUSE specific feature you mention above that does ‘catch-ups’ for missed cron jobs does not work now that logrotate is initiated by logrotate-timer.
Correct.
On 2015-04-17 13:26, cmcgrath5035 wrote:
>
> Interesting find - I had not seen that the default install had changed.
>
> I upgraded from 13.1 (and 12.3, 12.2, …) which likely explains my
> environment.
Yes.
> I’ll assume you did a clean 13.2 install.
>
> And I’ll further assume that part of this disconnect with logrotate and
> systemd is that in a ‘clean’ systemd system, there are no logs to
> rotate.
No, not completely correct.
With systemd you get a log system, accessed via the command
“journalctl”. The store is binary, and does not rotate; as far as I
know, when the size is exceeded, old entries are lost.
When you upgrade a system, as you have a syslog daemon, this take care
of writing the traditional text logs. So you may in fact have both systems.
On a freshly installed 13.2 you don’t. However, there are daemons and
applications that write their own text logs directly, without an
intervening syslog daemon. And these need to be rotated.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On 2015-04-18 14:16, wolfi323 wrote:
> But (open)SUSE contains a script (that’s started by cron every 15
> minutes) to run jobs in /etc/cron.d/, /etc/cron.daily/ and
> /etc/cron.weekly.
Does this script still exist in 13.2? I’m assuming that it exists, but
does not call logrotate.
I wonder if the script still exists, you can use it to also call the new
systemd timer. Or find out if logrotate did not run in the last 24
hours, then call it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))