[support][TW] logrotate zypper.log
On a PC that sees only occasional use, I'm using what appears to be default files in /etc/logrotate.d/, timestamped Oct 2018. zypper.lr there specifies size 10M. After a reboot with its size exceeding 10M, e.g. 25,000K, it remains the same size until some later unknown time or number of boots when it finally gets rotated and shrunk. Why? How can rotating and compressing it be made to happen when on boot it is found to exceed the configured limit. Is it simply that logrotate needs to be forced to run other than via a daily cron job? If yes, what is a good method? If not, how? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Fri, 24 Jun 2022 02:33:24 -0400
Felix Miata
On a PC that sees only occasional use, I'm using what appears to be default files in /etc/logrotate.d/, timestamped Oct 2018. zypper.lr there specifies size 10M. After a reboot with its size exceeding 10M, e.g. 25,000K, it remains the same size until some later unknown time or number of boots when it finally gets rotated and shrunk. Why? How can rotating and compressing it be made to happen when on boot it is found to exceed the configured limit. Is it simply that logrotate needs to be forced to run other than via a daily cron job? If yes, what is a good method? If not, how?
You don't mention what version of OS you're using or what version of logrotate come to that, so guesswork ... You know you can use @reboot as a cron time-specifier right? And ISTR in more modern OS that logrotate is controlled via systemd instead.
On 24.06.2022 09:33, Felix Miata wrote:
On a PC that sees only occasional use, I'm using what appears to be default files in /etc/logrotate.d/, timestamped Oct 2018. zypper.lr there specifies size 10M. After a reboot with its size exceeding 10M, e.g. 25,000K, it remains the same size until some later unknown time or number of boots when it finally gets rotated and shrunk. Why? How can rotating and compressing it be made to happen when on boot it is found to exceed the configured limit. Is it simply that logrotate needs to be forced to run other than via a daily cron job? If yes, what is a good method? If not, how?
You could start with telling you openSUSE version.
^^^^ Re: [support][TW] logrotate zypper.log Andrei Borzenkov composed on 2022-06-24 08:04 (UTC-0400)
Felix Miata wrote:
On a PC that sees only occasional use, I'm using what appears to be default files in /etc/logrotate.d/, timestamped Oct 2018. zypper.lr there specifies size 10M. After a reboot with its size exceeding 10M, e.g. 25,000K, it remains the same size until some later unknown time or number of boots when it finally gets rotated and shrunk. Why? How can rotating and compressing it be made to happen when on boot it is found to exceed the configured limit. Is it simply that logrotate needs to be forced to run other than via a daily cron job? If yes, what is a good method? If not, how?
You could start with telling you openSUSE version.
It changes most days: 20220623, 20220622, 20220619, 20220618, 20220617.... -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 24.06.2022 15:21, Felix Miata wrote:
^^^^ Re: [support][TW] logrotate zypper.log
Andrei Borzenkov composed on 2022-06-24 08:04 (UTC-0400)
Felix Miata wrote:
On a PC that sees only occasional use, I'm using what appears to be default files in /etc/logrotate.d/, timestamped Oct 2018. zypper.lr there specifies size 10M. After a reboot with its size exceeding 10M, e.g. 25,000K, it remains the same size until some later unknown time or number of boots when it finally gets rotated and shrunk. Why? How can rotating and compressing it be made to happen when on boot it is found to exceed the configured limit. Is it simply that logrotate needs to be forced to run other than via a daily cron job? If yes, what is a good method? If not, how?
You could start with telling you openSUSE version.
It changes most days: 20220623, 20220622, 20220619, 20220618, 20220617....
On Tumbleweed logrotate is controlled by logrotate.timer which by default runs every day and has Persistent option which means, if it missed run (because system was not up) it should immediately activate service during boot. Check logrotate.timer (is it enabled, when was the last time it run etc).
Andrei Borzenkov composed on 2022-06-24 15:34 (UTC+0300):
On Tumbleweed logrotate is controlled by logrotate.timer which by default runs every day and has Persistent option which means, if it missed run (because system was not up) it should immediately activate service during boot. Check logrotate.timer (is it enabled, when was the last time it run etc).
Apparently the problem is at least in part the immediate activation on a new boot, a boot on which a large quantity of transactions subsequently transpire from zypper dup after a lengthy period of no booting. It compacts the old file with the current date, then on a subsequent boot following a new kernel installation and massive zypper.log growth, it refuses to compact the gigantic new log file because a rotated file with the current date already exists. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 24.06.2022 22:46, Felix Miata wrote:
Andrei Borzenkov composed on 2022-06-24 15:34 (UTC+0300):
On Tumbleweed logrotate is controlled by logrotate.timer which by default runs every day and has Persistent option which means, if it missed run (because system was not up) it should immediately activate service during boot. Check logrotate.timer (is it enabled, when was the last time it run etc).
Apparently the problem is at least in part the immediate activation on a new boot, a boot on which a large quantity of transactions subsequently transpire from zypper dup after a lengthy period of no booting. It compacts the old file with the current date, then on a subsequent boot following a new kernel installation and massive zypper.log growth,
You seriously say that one zypper dup results in 10M log file?
it refuses to compact the gigantic new log file because a rotated file with the current date already exists.
In default configuration logrotate.timer will trigger service once a day.
Andrei Borzenkov composed on 2022-06-25 07:35 (UTC+0300):
Felix Miata wrote:
Apparently the problem is at least in part the immediate activation on a new boot, a boot on which a large quantity of transactions subsequently transpire from zypper dup after a lengthy period of no booting. It compacts the old file with the current date, then on a subsequent boot following a new kernel installation and massive zypper.log growth,
You seriously say that one zypper dup results in 10M log file?
# ls -gGh zypp* -rw-r----- 1 17M Jun 3 20:08 zypper.log -rw-r----- 1 799K Mar 30 19:08 zypper.log-20220603.xz zypp: total 4.9M -rw-rw-r-- 1 4.9M Jun 3 20:08 history # head -n2 zypper.log 2022-06-03 19:24:22 <1> <>(2140) [zypper] main.cc(main):125 ===== Hi, me zypper 1.14.52 2022-06-03 19:24:22 <1> <>(2140) [zypper] main.cc(main):126 ===== 'zypper' 'ref' ===== # tail -n2 zypper.log 2022-06-03 20:08:13 <1> <>(15102) [zypper] Zypper.cc(cleanup):729 START 2022-06-03 20:08:13 <1> <>(15102) [zypper] main.cc(~Bye):98 ===== Exiting main(0) ===== # grep zypper zypper.log | grep "'dup' '-d'" 2022-06-03 19:26:05 <1> <>(2426) [zypper] main.cc(main):126 ===== 'zypper' '-v' 'dup' '-d' ===== The above 17M file is probably below average size of what I see around here. I think more often I see 20M+ or 30M+ than I see less than that, except right after a fresh rotate. The dup actually begins about 2% into the log preceded by the ref. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Felix Miata wrote:
Andrei Borzenkov composed on 2022-06-25 07:35 (UTC+0300):
You seriously say that one zypper dup results in 10M log file?
# ls -gGh zypp* -rw-r----- 1 17M Jun 3 20:08 zypper.log -rw-r----- 1 799K Mar 30 19:08 zypper.log-20220603.xz
zypp: total 4.9M -rw-rw-r-- 1 4.9M Jun 3 20:08 history # head -n2 zypper.log 2022-06-03 19:24:22 <1> <>(2140) [zypper] main.cc(main):125 ===== Hi, me zypper 1.14.52 2022-06-03 19:24:22 <1> <>(2140) [zypper] main.cc(main):126 ===== 'zypper' 'ref' ===== # tail -n2 zypper.log 2022-06-03 20:08:13 <1> <>(15102) [zypper] Zypper.cc(cleanup):729 START 2022-06-03 20:08:13 <1> <>(15102) [zypper] main.cc(~Bye):98 ===== Exiting main(0) ===== # grep zypper zypper.log | grep "'dup' '-d'" 2022-06-03 19:26:05 <1> <>(2426) [zypper] main.cc(main):126 ===== 'zypper' '-v' 'dup' '-d' =====
The above 17M file is probably below average size of what I see around here. I think more often I see 20M+ or 30M+ than I see less than that, except right after a fresh rotate. The dup actually begins about 2% into the log preceded by the ref.
I see comparable sizes here, with one dup making 90% of an 18MB file. Though those are (probably?) from one of the complete rebuilds. (?) My laptop likely also has larger ones, as it has a lot more packages installed (but it's off in the office ATM, so I cannot verify).
participants (4)
-
Andrei Borzenkov -
Dave Howorth -
Felix Miata -
Peter Suetterlin