[opensuse-factory] 37M in /var/log/zypper.log
On one TW system, freespace on / is in seriously short supply. Shrinking this log looks like would put a serious dent in the problem, if its content made any sense. It covers a span of only 27 days. /etc/logrotate.d/ has 3 zypp* files, none of which look like might allow a log to get so large. No man page for zypper.log. /var/log/messages is big too, 18M, and /var/log/pbl.log is 13M. Ideas? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-19 23:37, Felix Miata wrote:
On one TW system, freespace on / is in seriously short supply. Shrinking this log looks like would put a serious dent in the problem, if its content made any sense. It covers a span of only 27 days. /etc/logrotate.d/ has 3 zypp* files, none of which look like might allow a log to get so large. No man page for zypper.log. /var/log/messages is big too, 18M, and /var/log/pbl.log is 13M. Ideas?
Those are not that big. If it were gigabytes, nor megabytes... Anyway. There is a systemd timer job that should run logrotate periodically. in 13.2, if the machine is not powered up at the exact required time, logs never rotate. I don't know if the situation has been corrected yet in TW. (in 13.1 and earlier the situation does not arise, the problem was solved decades ago) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVbxKsACgkQja8UbcUWM1xg7wD8Cf3SqiETbRmUcSiRcEB2gbdB e2gtUhDHA3S5IF31ESgBAIHzJLaUhJPKrko9QM3PjXBq5Zc4MIbqkVlWm/Amecpv =KF9q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, May 19, 2015 at 8:18 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Anyway. There is a systemd timer job that should run logrotate periodically. in 13.2, if the machine is not powered up at the exact required time, logs never rotate. I don't know if the situation has been corrected yet in TW.
I just did. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Wed, 20 May 2015 01:18:03 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-05-19 23:37, Felix Miata wrote:
On one TW system, freespace on / is in seriously short supply. Shrinking this log looks like would put a serious dent in the problem, if its content made any sense. It covers a span of only 27 days. /etc/logrotate.d/ has 3 zypp* files, none of which look like might allow a log to get so large. No man page for zypper.log. /var/log/messages is big too, 18M, and /var/log/pbl.log is 13M. Ideas?
Those are not that big. If it were gigabytes, nor megabytes...
Anyway. There is a systemd timer job that should run logrotate periodically. in 13.2, if the machine is not powered up at the exact required time, logs never rotate.
bor@opensuse:~> LC_ALL=C ll /var/log/zypper.log* - -rw-r----- 1 root root 13531358 May 19 19:59 /var/log/zypper.log - -rw-r----- 1 root root 4725804 Mar 12 20:51 /var/log/zypper.log-20150315.xz - -rw-r----- 1 root root 314160 Mar 28 07:40 /var/log/zypper.log-20150329.xz - -rw-r----- 1 root root 416284 Apr 18 11:04 /var/log/zypper.log-20150419.xz bor@opensuse:~> cat /etc/os-release NAME=openSUSE VERSION="13.2 (Harlequin)" This is notebook which is put to sleep at least twice a day. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVcAwwACgkQR6LMutpd94xk5wCggYOC6aTsYkTTpyKXUy+y9AUN k4UAniAUfNSOD+OkI7PF61L6uIqJ9eis =d1hl -----END PGP SIGNATURE-----
On 2015-05-20 05:44, Andrei Borzenkov wrote:
В Wed, 20 May 2015 01:18:03 +0200 "Carlos E. R." <> пишет:
This is notebook which is put to sleep at least twice a day.
The problem exists. Cristian just wrote that he solved the issue, but has not mentioned how, or what people need to do to get it. Maybe it is a patch for factory, so does not apply to 13.2, unless it can be backported. Maybe your machine was running at the precise time. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, May 20, 2015 at 7:43 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2015-05-20 05:44, Andrei Borzenkov wrote:
В Wed, 20 May 2015 01:18:03 +0200 "Carlos E. R." <> пишет:
This is notebook which is put to sleep at least twice a day.
The problem exists. Cristian just wrote that he solved the issue, but has not mentioned how, or what people need to do to get it. Maybe it is a patch for factory, so does not apply to 13.2, unless it can be backported.
Making the timer persistent --> http://www.freedesktop.org/software/systemd/man/systemd.timer.html There is no such feature in 13.2 ' systemd version however. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-05-20 17:59, Cristian Rodríguez wrote:
On Wed, May 20, 2015 at 7:43 AM, Carlos E. R. <> wrote:
On 2015-05-20 05:44, Andrei Borzenkov wrote:
В Wed, 20 May 2015 01:18:03 +0200 "Carlos E. R." <> пишет:
This is notebook which is put to sleep at least twice a day.
The problem exists. Cristian just wrote that he solved the issue, but has not mentioned how, or what people need to do to get it. Maybe it is a patch for factory, so does not apply to 13.2, unless it can be backported.
Making the timer persistent --> http://www.freedesktop.org/software/systemd/man/systemd.timer.html There is no such feature in 13.2 ' systemd version however.
Thanks. Then it can not be backported. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, 20 May 2015 20:29:40 +0200 Carlos E. R. wrote:
Making the timer persistent --> http://www.freedesktop.org/software/systemd/man/systemd.timer.html There is no such feature in 13.2 ' systemd version however.
Thanks.
Then it can not be backported.
for 13.2 there is a workaround documented in https://bugzilla.suse.com/show_bug.cgi?id=913421 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
dieter composed on 2015-05-20 22:31 (UTC+0200):
On Wed, 20 May 2015 20:29:40 +0200
Carlos E. R. wrote:
Making the timer persistent --> http://www.freedesktop.org/software/systemd/man/systemd.timer.html There is no such feature in 13.2 ' systemd version however.
Then it can not be backported.
for 13.2 there is a workaround documented in https://bugzilla.suse.com/show_bug.cgi?id=913421
And for those opensuse-factory subscribers who use openSUSE's bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=913421 # grep suse /etc/hosts 0.0.0.0 bugzilla.suse.com Anyone know a better way for opensuse-factory subscribers and bugzilla.opensuse.org users to keep bugzilla.novell.com and bugzilla.suse.com URLs from cluttering browser history? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Wed, 20 May 2015 12:43:34 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
On 2015-05-20 05:44, Andrei Borzenkov wrote:
В Wed, 20 May 2015 01:18:03 +0200 "Carlos E. R." <> пишет:
This is notebook which is put to sleep at least twice a day.
The problem exists. Cristian just wrote that he solved the issue, but has not mentioned how, or what people need to do to get it. Maybe it is a patch for factory, so does not apply to 13.2, unless it can be backported.
Maybe your machine was running at the precise time.
logrotate.timer has 12 hours accuracy with daily run which means system must be on some time between 00:00 and 12:00. The possible problem for those who *updated* to 13.2 was that systemd.timer did not get activated on update. This is unfortunate situation that was discussed on systemd list but I do not think any resolution is available - there is no way to know whether unit is not active because it simply was not activated or because it was intentionally not or deactivated. So even though defaults are changed to enable service, these defaults are not reapplied on update.
On 2015-05-20 19:52, Andrei Borzenkov wrote:
В Wed, 20 May 2015 12:43:34 +0200 "Carlos E. R." <> пишет:
logrotate.timer has 12 hours accuracy with daily run which means system must be on some time between 00:00 and 12:00. The possible problem for those who *updated* to 13.2 was that systemd.timer did not get activated on update. This is unfortunate situation that was discussed on systemd list but I do not think any resolution is available - there is no way to know whether unit is not active because it simply was not activated or because it was intentionally not or deactivated. So even though defaults are changed to enable service, these defaults are not reapplied on update.
Then Felix has to check that :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2015-05-20 20:33 (UTC+0200):
Andrei Borzenkov wrote:
logrotate.timer has 12 hours accuracy with daily run which means system must be on some time between 00:00 and 12:00. The possible problem for those who *updated* to 13.2 was that systemd.timer did not get activated on update. This is unfortunate situation that was discussed on systemd list but I do not think any resolution is available - there is no way to know whether unit is not active because it simply was not activated or because it was intentionally not or deactivated. So even though defaults are changed to enable service, these defaults are not reapplied on update.
Then Felix has to check that :-)
Check what how? My TW test systems are often run between 00:00 and 05:00, infrequently between 05:00 and 12:00, and usually less than an hour at a time. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-05-20 21:34, Felix Miata wrote:
Carlos E. R. composed on 2015-05-20 20:33 (UTC+0200):
Andrei Borzenkov wrote:
logrotate.timer has 12 hours accuracy with daily run which means system must be on some time between 00:00 and 12:00. The possible problem for those who *updated* to 13.2 was that systemd.timer did not get activated on update. This is unfortunate situation that was discussed on systemd list but I do not think any resolution is available - there is no way to know whether unit is not active because it simply was not activated or because it was intentionally not or deactivated. So even though defaults are changed to enable service, these defaults are not reapplied on update.
Then Felix has to check that :-)
Check what how? My TW test systems are often run between 00:00 and 05:00, infrequently between 05:00 and 12:00, and usually less than an hour at a time.
Check that the timer is enabled. I understand the name is "systemd.timer". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, May 20, 2015 at 10:45 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2015-05-20 21:34, Felix Miata wrote:
Carlos E. R. composed on 2015-05-20 20:33 (UTC+0200):
Andrei Borzenkov wrote:
logrotate.timer has 12 hours accuracy with daily run which means system must be on some time between 00:00 and 12:00. The possible problem for those who *updated* to 13.2 was that systemd.timer did not get activated on update. This is unfortunate situation that was discussed on systemd list but I do not think any resolution is available - there is no way to know whether unit is not active because it simply was not activated or because it was intentionally not or deactivated. So even though defaults are changed to enable service, these defaults are not reapplied on update.
Then Felix has to check that :-)
Check what how? My TW test systems are often run between 00:00 and 05:00, infrequently between 05:00 and 12:00, and usually less than an hour at a time.
Check that the timer is enabled. I understand the name is "systemd.timer".
Sorry, was a typo. It was logrotate.timer of course. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
Cristian Rodríguez -
dieter -
Felix Miata