[opensuse] logrotate is not running
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 minas-tirith:~ # grep -i logrotate /var/log/messages <1.6> 2017-11-03 18:45:24 minas-tirith run-crons 29173 - - logrotate: OK <1.6> 2017-11-09 23:15:10 minas-tirith run-crons 26985 - - logrotate: OK <1.6> 2017-11-15 02:15:12 minas-tirith run-crons 30572 - - logrotate: OK <1.6> 2017-11-20 22:45:11 minas-tirith run-crons 6757 - - logrotate: OK <1.6> 2017-12-05 21:15:12 minas-tirith run-crons 30613 - - logrotate: OK <1.6> 2017-12-11 09:15:11 minas-tirith run-crons 2495 - - logrotate: OK <1.6> 2017-12-18 01:45:13 minas-tirith run-crons 5130 - - logrotate: OK <1.6> 2018-01-02 10:45:17 minas-tirith run-crons 10574 - - logrotate: OK <1.6> 2018-01-15 18:30:16 minas-tirith run-crons 19341 - - logrotate: OK <1.6> 2018-01-20 22:15:14 minas-tirith run-crons 17631 - - logrotate: OK <1.6> 2018-01-26 12:15:12 minas-tirith run-crons 3707 - - logrotate: OK minas-tirith:~ # As you can see, it did not run since January, when I updated the machine to Leap 42.3 It is supposed to be a systemd timer now, and it was disabled. I enabled it yesterday and waited a day. But it is not running, on two computers - notice the size of the messages log file: minas-tirith:~ # l -h /var/log/messages - -rw-r----- 1 root root 20M Jul 7 01:45 /var/log/messages minas-tirith:~ # Isengard:~ # grep -i logrotate /var/log/messages Isengard:~ # ls -lh /var/log/messages - -rw-r----- 1 root root 99M Jul 7 01:45 /var/log/messages Isengard:~ # It should rotate at 4 MB: /etc/logrotate.d/syslog: /var/log/warn /var/log/messages /var/log/localmessages /var/log/firewall /var/log/acpid /var/log/NetworkManager /var/log/mail /var/log/mail.info /var/log/mail.warn /var/log/mail.err { compress dateext maxage 365 rotate 99 missingok notifempty size +4096k create 640 root root sharedscripts postrotate /usr/bin/systemctl reload syslog.service > /dev/null endscript } The timer is enabled on one, but after a day it did not run: minas-tirith:~ # systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5) minas-tirith:~ # systemctl status logrotate.service ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5) minas-tirith:~ # Isengard:~ # systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5) Isengard:~ # systemctl status logrotate.service ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5) Isengard:~ # On this machine I did no change till now: Isengard:~ # systemctl enable logrotate.timer Created symlink from /etc/systemd/system/timers.target.wants/logrotate.timer to /usr/lib/systemd/system/logrotate.timer. Isengard:~ # What is missing? Should I also enable the service? start the timer and/or the service? I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow? I noticed the problem because yesterday this machine root partition was full with one log that had grown to 8 GB and not rotated :-( - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAltAAlgACgkQja8UbcUWM1yrewEAnH913rAjgb/dFcrE/6gBqnIr Q68J7PZ+gwvMHTEQhUgA/3Cw3T0+jEgHKqPB3bNI3azZOlnOROW+Zd8Q7dd09RE1 =1IyJ -----END PGP SIGNATURE-----
* Carlos E. R. <robin.listas@telefonica.net> [07-06-18 20:00]: [...]
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
you do not have to wait unless you are testing the systemd-timer action. you can initiate logrotate from the cl. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [07-06-18 20:21]:
* Carlos E. R. <robin.listas@telefonica.net> [07-06-18 20:00]:
[...]
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
you do not have to wait unless you are testing the systemd-timer action. you can initiate logrotate from the cl.
I would suggest manually running logrotate on one or two of your largest logs and then wait to see if systemd-timer daemon does as expected. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2018-07-06 a las 20:23 -0400, Patrick Shanahan escribió:
* Patrick Shanahan <> [07-06-18 20:21]:
* Carlos E. R. <robin.listas@telefonica.net> [07-06-18 20:00]:
[...]
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
you do not have to wait unless you are testing the systemd-timer action. you can initiate logrotate from the cl.
But I want to make sure that the timer is working. If I do that, it will not trigger this week till the logs grow again, and I will forget to watch.
I would suggest manually running logrotate on one or two of your largest logs and then wait to see if systemd-timer daemon does as expected.
I already rotated (I manually compressed and renamed) the largest files, so I can wait. - -- Cheers Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAltACUgACgkQja8UbcUWM1zVEwD+N2bkEBn02XIaxa3JmwR2kXlO rbYUj5hSa3QzYt+WscAA/1T/ecpyEBJmaISZczTiNWxKIcdg2NoMkhjGd13AmEcz =qnEV -----END PGP SIGNATURE-----
* Carlos E. R. <robin.listas@telefonica.net> [07-06-18 20:29]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2018-07-06 a las 20:23 -0400, Patrick Shanahan escribió:
* Patrick Shanahan <> [07-06-18 20:21]:
* Carlos E. R. <robin.listas@telefonica.net> [07-06-18 20:00]:
[...]
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
you do not have to wait unless you are testing the systemd-timer action. you can initiate logrotate from the cl.
But I want to make sure that the timer is working. If I do that, it will not trigger this week till the logs grow again, and I will forget to watch.
then set the trigger to an earlier time or condition. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-07 02:39, Patrick Shanahan wrote:
* Carlos E. R. <> [07-06-18 20:29]:
El 2018-07-06 a las 20:23 -0400, Patrick Shanahan escribió:
* Patrick Shanahan <> [07-06-18 20:21]:
* Carlos E. R. <robin.listas@telefonica.net> [07-06-18 20:00]:
[...]
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
you do not have to wait unless you are testing the systemd-timer action. you can initiate logrotate from the cl.
But I want to make sure that the timer is working. If I do that, it will not trigger this week till the logs grow again, and I will forget to watch.
then set the trigger to an earlier time or condition.
How? The timer says: [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) [Timer] OnCalendar=daily AccuracySec=12h Persistent=true [Install] WantedBy=timers.target It doesn't say there that it is going to run once per day at 00, but it does. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
How? The timer says:
[Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer] OnCalendar=daily AccuracySec=12h Persistent=true
[Install] WantedBy=timers.target
It doesn't say there that it is going to run once per day at 00,
It does actually say that above too, but you have to know the syntax. "OnCalendar=daily" means "daily at 00:00" man systemd.time -- Per Jessen, Zürich (22.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-07 13:51, Per Jessen wrote:
Carlos E. R. wrote:
How? The timer says:
[Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer] OnCalendar=daily AccuracySec=12h Persistent=true
[Install] WantedBy=timers.target
It doesn't say there that it is going to run once per day at 00,
It does actually say that above too, but you have to know the syntax.
"OnCalendar=daily" means "daily at 00:00"
man systemd.time
Ah. You also have to know what man page. I thought it would be "timer" What happens when the computer is not powered at 00:00, when does it run? The manual says "Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the AccuracySec= setting below." Hum. So it may run 12 hours later - but if I power the computer at 13 hours, it will not run. Huh. "To optimize power consumption, make sure to set this value as high as possible and as low as necessary." What the...? Ah: Persistent= Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. This is useful to catch up on missed runs of the service when the machine was off. Note that this setting only has an effect on timers configured with OnCalendar=. Hum. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-07-07 13:51, Per Jessen wrote:
Carlos E. R. wrote:
How? The timer says:
[Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer] OnCalendar=daily AccuracySec=12h Persistent=true
[Install] WantedBy=timers.target
It doesn't say there that it is going to run once per day at 00,
It does actually say that above too, but you have to know the syntax.
"OnCalendar=daily" means "daily at 00:00"
man systemd.time
Ah.
You also have to know what man page. I thought it would be "timer"
It is, and "man systemd.timer" then refers to systemd.time for the calendar format. :-)
What happens when the computer is not powered at 00:00, when does it run?
"man systemd.timer" - look for AccuracySec
The manual says "Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the AccuracySec= setting below." Hum. So it may run 12 hours later - but if I power the computer at 13 hours, it will not run.
Yup, there you have it. -- Per Jessen, Zürich (22.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
07.07.2018 15:06, Carlos E. R. пишет:
On 2018-07-07 13:51, Per Jessen wrote:
Carlos E. R. wrote:
How? The timer says:
[Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer] OnCalendar=daily AccuracySec=12h Persistent=true
[Install] WantedBy=timers.target
It doesn't say there that it is going to run once per day at 00,
It does actually say that above too, but you have to know the syntax.
"OnCalendar=daily" means "daily at 00:00"
man systemd.time
Ah.
You also have to know what man page. I thought it would be "timer"
Did you even try to read the man page you thought would be the right one?
On 2018-07-07 15:30, Andrei Borzenkov wrote:
07.07.2018 15:06, Carlos E. R. пишет:
On 2018-07-07 13:51, Per Jessen wrote:
Carlos E. R. wrote:
How? The timer says:
[Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer] OnCalendar=daily AccuracySec=12h Persistent=true
[Install] WantedBy=timers.target
It doesn't say there that it is going to run once per day at 00,
It does actually say that above too, but you have to know the syntax.
"OnCalendar=daily" means "daily at 00:00"
man systemd.time
Ah.
You also have to know what man page. I thought it would be "timer"
Did you even try to read the man page you thought would be the right one?
You can see in my reply that I did ;-) But the file said to read man logrotate, which was not the one. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
As you can see, it did not run since January, when I updated the machine to Leap 42.3
It is supposed to be a systemd timer now, and it was disabled.
Yes, on an upgrade it is not enabled. It is a well-known issue, to me anyway :-) I think it's been mentioned a few times before. [snip]
What is missing? Should I also enable the service? start the timer and/or the service?
Unless you have rebooted, you have to start the timer, definitely.
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
systemctl list-timers -- Per Jessen, Zürich (18.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 07 Jul 2018 10:24:21 +0200 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
As you can see, it did not run since January, when I updated the machine to Leap 42.3
It is supposed to be a systemd timer now, and it was disabled.
Yes, on an upgrade it is not enabled. It is a well-known issue, to me anyway :-) I think it's been mentioned a few times before.
Hmm, it's not well-known to me. I too see that I have a whole bunch of messages-*.xz files with the last one being at 20180111 and a single large messages file, so I presume I have the same problem. I don't understand why an upgrade should stop a system process from working. If it was migrated to a new mechanism then the migration should have migrated the settings.
[snip]
What is missing? Should I also enable the service? start the timer and/or the service?
Unless you have rebooted, you have to start the timer, definitely.
What timer is this? There's only one systemd timer listed on my machine. Are there instructions somewhere on how to get logrotate to do what it used to do? Or a bug report on this issue, perhaps? TIA, Dave
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
systemctl list-timers
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Sat, 07 Jul 2018 10:24:21 +0200 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
As you can see, it did not run since January, when I updated the machine to Leap 42.3
It is supposed to be a systemd timer now, and it was disabled.
Yes, on an upgrade it is not enabled. It is a well-known issue, to me anyway :-) I think it's been mentioned a few times before.
Hmm, it's not well-known to me.
Yeah, I wanted to be careful - I'm not sure if it's the release notes either. I searched bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1064303 https://bugzilla.opensuse.org/show_bug.cgi?id=908279
I too see that I have a whole bunch of messages-*.xz files with the last one being at 20180111 and a single large messages file, so I presume I have the same problem.
Sounds much like it.
I don't understand why an upgrade should stop a system process from working. If it was migrated to a new mechanism then the migration should have migrated the settings.
I agree. On a new installation it would have, courtesy of systemd presets (or whatever it is called).
[snip]
What is missing? Should I also enable the service? start the timer and/or the service?
Unless you have rebooted, you have to start the timer, definitely.
What timer is this? There's only one systemd timer listed on my machine.
logrotate.timer -- Per Jessen, Zürich (21.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 07 Jul 2018 13:23:02 +0200 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
On Sat, 07 Jul 2018 10:24:21 +0200 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
As you can see, it did not run since January, when I updated the machine to Leap 42.3
It is supposed to be a systemd timer now, and it was disabled.
Yes, on an upgrade it is not enabled. It is a well-known issue, to me anyway :-) I think it's been mentioned a few times before.
Hmm, it's not well-known to me.
Yeah, I wanted to be careful - I'm not sure if it's the release notes either.
I searched bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1064303 https://bugzilla.opensuse.org/show_bug.cgi?id=908279
Thanks Per. It seems the actual instructions are at the end of https://bugzilla.opensuse.org/show_bug.cgi?id=1054353 Thanks also to Carlos for providing the same instructions.
I too see that I have a whole bunch of messages-*.xz files with the last one being at 20180111 and a single large messages file, so I presume I have the same problem.
Sounds much like it.
I don't understand why an upgrade should stop a system process from working. If it was migrated to a new mechanism then the migration should have migrated the settings.
I agree. On a new installation it would have, courtesy of systemd presets (or whatever it is called).
[snip]
What is missing? Should I also enable the service? start the timer and/or the service?
Unless you have rebooted, you have to start the timer, definitely.
What timer is this? There's only one systemd timer listed on my machine.
logrotate.timer
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/7/2018 7:20 AM, Dave Howorth wrote:
I searched bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1064303 https://bugzilla.opensuse.org/show_bug.cgi?id=908279 Thanks Per. It seems the actual instructions are at the end of https://bugzilla.opensuse.org/show_bug.cgi?id=1054353
Thanks also to Carlos for providing the same instructions.
Seems this is one place openSuSE could take a bit of functionality from Arch. Arch keeps a feed of its "release notes" as the left section of it's home page, as well as a feed of recent package updates. So there is never a question whether someone found or read the release notes or whether an update is ready. That information is instantly available (which also bodes well for a "useful" website) By contrast the opensuse home page looks like a cheerleading competition flyer between Tumbleweed and Leap. (the page even does tumbling runs in from the side and flip-flops for you, even though you didn't ask it to) Having the release notes somewhere on the install media or as a page as part of the installer containing 300 lines of text -- almost guarantees they will be overlooked (or intentionally skipped) by virtue of good old human-nature. I know I'm guilty of it when I'm in a hurry to get an update done. Understanding human-nature and working with it, instead of against it, goes a long way in disseminating information. As far as the 42.3+ logrotate goes, seems like zypper or yast should be able to spit out "install notes" into install log that could check if logrotate was installed as spit out a short message on update that => logrotate was disabled on update. To restart the service: systemctl enable logrotate systemctl restart logrotate Just another handy avenue for getting this type of info across. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-07 12:49, Dave Howorth wrote:
On Sat, 07 Jul 2018 10:24:21 +0200 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
As you can see, it did not run since January, when I updated the machine to Leap 42.3
It is supposed to be a systemd timer now, and it was disabled.
Yes, on an upgrade it is not enabled. It is a well-known issue, to me anyway :-) I think it's been mentioned a few times before.
Hmm, it's not well-known to me. I too see that I have a whole bunch of messages-*.xz files with the last one being at 20180111 and a single large messages file, so I presume I have the same problem.
I knew about the issue, but I had thought it had been solved by now.
I don't understand why an upgrade should stop a system process from working. If it was migrated to a new mechanism then the migration should have migrated the settings.
Yes, it is a faulty migration.
[snip]
What is missing? Should I also enable the service? start the timer and/or the service?
Unless you have rebooted, you have to start the timer, definitely.
What timer is this? There's only one systemd timer listed on my machine.
Are there instructions somewhere on how to get logrotate to do what it used to do? Or a bug report on this issue, perhaps?
Apparently: systemctl status logrotate.timer systemctl enable logrotate.timer systemctl start logrotate.timer systemctl status logrotate.timer
I just told the timer to start, I'll hope it is that but I do not know. How much do I have to wait till the logs are rotated, till 00 hours tomorrow?
systemctl list-timers
Ah.
Isengard:~ # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sun 2018-07-08 00:00:00 CEST 10h left n/a n/a logrotate.timer logrotate.service Sun 2018-07-08 13:06:49 CEST 23h left Sat 2018-07-07 13:06:49 CEST 22min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Mon 2018-07-09 00:00:00 CEST 1 day 10h left Mon 2018-07-02 00:00:01 CEST 5 days ago fstrim.timer fstrim.service
3 timers listed. Pass --all to see loaded but inactive timers, too. Isengard:~ #
-- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
Patrick Shanahan -
Per Jessen