[opensuse-factory] HEADS-UP: logrotate changes
Hi: Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;) - Logrotate no longer runs as a cronjob but as a systemd.timer(5) - You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer - It continues to run just like "cron.daily" with the following bonus perks: * Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time. * The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later) * If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue: systemctl status logrotate.service logrotate.timer Observed problems/gotchas: zypp installs packages in an unsuitable order, systemd-presets that enable the timer by default may be installed after the logrotate update. thus it does not get automatically enabled. to ensure things keep running smoothly in your factory installation: $ systemctl enable logrotate.timer $ systemctl start logrotate.timer Have a lot of fun :-) -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
Hi:
Today an update to logrotate has hit the factory repositories and I
I have a question -- in addition to running the system logrotations, I also have my logrotate rotate some user logs. So the system logrotate ran out of /etc/cron.daily, while the one for my log files runs out of my user-crontab. Should there be any difference for me running it out of my crontab while the system instance will normally be running via systemd? FWIW, I resent several of Redhat's changes that disallow group control of system files...having logrotate check that it is only writable by the 'root' UID disallows group-wheel based management policies (or me in group 'root', being more to the point). Additionally the requirement to have all the files that are rotated to be owned and writable only as root was a further annoyance. Does suse need to take all the crap RH puts out -- not that they don't put out lots of good stuff too, but lately some of their security changes have been "less than well thought out". Example -- most daemons run under their own UID/GID on my system. That mean that many daemon-written logs wouldn't get rotated with the stock logrotate. Is that really what is wanted? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
Hi:
Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;)
- Logrotate no longer runs as a cronjob but as a systemd.timer(5)
- You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer
- It continues to run just like "cron.daily" with the following bonus perks:
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later)
All sounds pretty cool - question: can the feature above be disabled (to retain the current behaviour) ? -- Per Jessen, Zürich (12.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 05/04/14 05:53, Per Jessen escribió:
All sounds pretty cool - question: can the feature above be disabled (to retain the current behaviour) ?
No, it is one or the other, unless you write your own cron script and disable the timer. -- Cristian Team PITA -- 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 On 2014-04-05 02:57, Cristian Rodríguez wrote:
Hi:
Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;)
- Logrotate no longer runs as a cronjob but as a systemd.timer(5)
- You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer
- It continues to run just like "cron.daily" with the following bonus perks:
Nice... :-) Question, though: In "/etc/sysconfig/cron" there are variables like DAILY_TIME that allow us to choose a preferred time for these jobs to happen. Does systemd respect these choices? I expect not. Then, how do we configure preferred time? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM/9KAACgkQtTMYHG2NR9UyMACeIFlJ3c/wqWg8q/fF8Bbs01dG nycAniUjLsxOj6mBPoGpTIAhmYCXsYZd =AuJ6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 05/04/14 09:18, Carlos E. R. escribió:
In "/etc/sysconfig/cron" there are variables like DAILY_TIME that allow us to choose a preferred time for these jobs to happen.
Does systemd respect these choices?
No, it does not.
I expect not. Then, how do we configure preferred time?
Nope, there is no preffered time configuration. -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 05/04/14 11:03, Cristian Rodríguez escribió:
I expect not. Then, how do we configure preferred time?
Nope, there is no preffered time configuration.
Correction, yes, there is such equivalent, timer unit setting OnBootSec, you could also use it with combined with other On*Sec directives to achieve what you want. This is per unit though, not a global ugly hack^W^W setting :-) -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-04-05 16:21, Cristian Rodríguez wrote:
El 05/04/14 11:03, Cristian Rodríguez escribió:
I expect not. Then, how do we configure preferred time?
Nope, there is no preffered time configuration.
Correction, yes, there is such equivalent, timer unit setting OnBootSec, you could also use it with combined with other On*Sec directives to achieve what you want.
This is per unit though, not a global ugly hack^W^W setting :-)
I'll have to look this up. But you see, specially on servers, it is interesting that logs are rotated exactly at midnight. On other installations, they prefer the rotate to happen at a precise hour after that the internal periodical tasks are completed, like say, 5:43 AM. So, many people will need to be able to adjust somehow when the logs are rotated. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-04-05 16:21, Cristian Rodríguez wrote:
El 05/04/14 11:03, Cristian Rodríguez escribió:
I expect not. Then, how do we configure preferred time?
Nope, there is no preffered time configuration.
Correction, yes, there is such equivalent, timer unit setting OnBootSec, you could also use it with combined with other On*Sec directives to achieve what you want.
This is per unit though, not a global ugly hack^W^W setting :-)
I'll have to look this up.
But you see, specially on servers, it is interesting that logs are rotated exactly at midnight. On other installations, they prefer the rotate to happen at a precise hour after that the internal periodical tasks are completed, like say, 5:43 AM.
So, many people will need to be able to adjust somehow when the logs are rotated.
Here's my recipe: rm /etc/cron.daily/logrotate add your own cronjob. -- Per Jessen, Zürich (12.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-04-05 18:13, Per Jessen wrote:
Carlos E. R. wrote:
So, many people will need to be able to adjust somehow when the logs are rotated.
Here's my recipe:
rm /etc/cron.daily/logrotate add your own cronjob.
Oh, absolutely, but that's not the point: it is going to be handled directly by systemd. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-04-05 18:13, Per Jessen wrote:
Carlos E. R. wrote:
So, many people will need to be able to adjust somehow when the logs are rotated.
Here's my recipe:
rm /etc/cron.daily/logrotate add your own cronjob.
Oh, absolutely, but that's not the point: it is going to be handled directly by systemd.
I would still just disable the systemd timer for logrotate and run my own cronjob. -- Per Jessen, Zürich (16.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- 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 On 2014-04-06 15:03, Per Jessen wrote:
Carlos E. R. wrote:
I would still just disable the systemd timer for logrotate and run my own cronjob.
Yes, that's a possibility, of course. But I would like that modifications to openSUSE do not remove features. And in this case it was a much requested feature over many years. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNBVkkACgkQtTMYHG2NR9WGCgCeIyGGHaqJAD73qys1qNU/+GJg OIoAn0/YGkARBX0fpwkLekKjEgb2S1JX =M6G2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
I would still just disable the systemd timer for logrotate and run my own cronjob.
Yes, that's a possibility, of course. But I would like that modifications to openSUSE do not remove features. And in this case it was a much requested feature over many years.
You mean the user specifiable time to run the logrotations, not the move of logrotate into systemd, right? -- 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 2014-04-07 16:27, Linda Walsh wrote:
Carlos E. R. wrote:
I would still just disable the systemd timer for logrotate and run my own cronjob.
Yes, that's a possibility, of course. But I would like that modifications to openSUSE do not remove features. And in this case it was a much requested feature over many years. --- You mean the user specifiable time to run the logrotations, not the move of logrotate into systemd, right?
Right. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNCwAoACgkQja8UbcUWM1xkBAD9FGPjbPu7qzIx7tIx408Mwnj3 d8FlV7a36nwXCxFtGgYBAIfzChBYz+0k7siNjnPU3HCcTOwARXOByRqEFxddOOho =nYkP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 05/04/14 13:03, Carlos E. R. escribió:
On 2014-04-05 16:21, Cristian Rodríguez wrote:
But you see, specially on servers, it is interesting that logs are rotated exactly at midnight.
It depends on what your exact needs are, the current and previous behaviour is generic "once a day".. I for example will prefer the apache logs to rotate when a) there is very little or no HTTP traffic beign served [AND] b) the IO generated by logrotate does not slow down the rest of the system. "b" can be done currently, "a" requires knowledge of the server status. -- Cristian Team PITA -- 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 On 2014-04-05 19:00, Cristian Rodríguez wrote:
El 05/04/14 13:03, Carlos E. R. escribió:
On 2014-04-05 16:21, Cristian Rodríguez wrote:
But you see, specially on servers, it is interesting that logs are rotated exactly at midnight.
It depends on what your exact needs are, the current and previous behaviour is generic "once a day"..
Yes, I know, it has been that way for "decades". But since a few years ago it was modified so that you could set a preferred time of day (DAILY_TIME). You can tell it to run it always at 22:10, for instance. If it is not done at that exact time for a number of days (adjustable with MAX_NOT_RUN), it is then run at the first opportunity (within 15 minutes after booting or thawing). This particular feature had been requested often over the years. If DAILY_TIME is not set, you have the old behaviour instead. I like the new features you implemented, but I think it would be appreciated if you somehow added a way to also have that old feature as well. :-)
I for example will prefer the apache logs to rotate when
a) there is very little or no HTTP traffic beign served [AND] b) the IO generated by logrotate does not slow down the rest of the system.
True :-)
"b" can be done currently, "a" requires knowledge of the server status.
"uptime" gives the load status, but not the i/o load. :-? Another thing to consider. Currently, if logrotate fails (or any cron job) the administrator gets an email. What about that? If we don't notice that it fails, well... sometimes, people found about this when the partition filled up. I assume there would be entries in the warning log about the failure; but an email to the admin can be sent to your mobile phone, for instance, so that you can react. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNAfvQACgkQtTMYHG2NR9VaZQCghvMHezYnnbP1BdpkJl7KwSd0 +PcAnjhiJe3RSNwFw48LnbK7rNeqrZuo =mxOp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 05/04/14 19:08, Carlos E. R. escribió:
I like the new features you implemented, but I think it would be appreciated if you somehow added a way to also have that old feature as well. :-)
You can configure that by extending the unit configuration.
"b" can be done currently, "a" requires knowledge of the server status.
"uptime" gives the load status, but not the i/o load. :-?
It is not implemented that way, you simply tell the kernel IO scheduler to run the particular unit in a "best-effort" or "idle" fashion.
Another thing to consider. Currently, if logrotate fails (or any cron job) the administrator gets an email. What about that? If we don't notice that it fails, well... sometimes, people found about this when the partition filled up.
It has happended to me, I DOSed myself once, filled root partition with huge logs. :-) If syslog messages are not enough, we could extend logrotate that already has the capability to mail logs at will with the "mail*" configuration directives. Since systemd.timers are managed by PID1 is extremely unlikely that they will gain "annoying email message" capability. ;-) -- 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 On 2014-04-06 01:49, Cristian Rodríguez wrote:
El 05/04/14 19:08, Carlos E. R. escribió:
I like the new features you implemented, but I think it would be appreciated if you somehow added a way to also have that old feature as well. :-)
You can configure that by extending the unit configuration.
"b" can be done currently, "a" requires knowledge of the server status.
"uptime" gives the load status, but not the i/o load. :-?
It is not implemented that way, you simply tell the kernel IO scheduler to run the particular unit in a "best-effort" or "idle" fashion.
Another thing to consider. Currently, if logrotate fails (or any cron job) the administrator gets an email. What about that? If we don't notice that it fails, well... sometimes, people found about this when the partition filled up.
It has happended to me, I DOSed myself once, filled root partition with huge logs. :-)
If syslog messages are not enough, we could extend logrotate that already has the capability to mail logs at will with the "mail*" configuration directives.
Since systemd.timers are managed by PID1 is extremely unlikely that they will gain "annoying email message" capability. ;-)
IMO, I think you should reconsider those regressions. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNBLOQACgkQtTMYHG2NR9XkxgCfWqJnKsfwAilWIw6GSbSZENab PgUAnjONcVvKeF3UXceFg9nsLqGAp6Q8 =KoF8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2014-04-05 02:57, Cristian Rodríguez wrote:
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later) [...] Observed problems/gotchas:
zypp installs packages in an unsuitable order
The max-rpm book says that rpm tries to honor "Requires" requests also during installation, but I guess all that prior art is out the window given zypper does one transaction per package :/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 05/04/14 11:37, Jan Engelhardt escribió:
On Saturday 2014-04-05 02:57, Cristian Rodríguez wrote:
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later) [...] Observed problems/gotchas:
zypp installs packages in an unsuitable order
The max-rpm book says that rpm tries to honor "Requires" requests also during installation, but I guess all that prior art is out the window given zypper does one transaction per package :/
Even if zypp did honour this..there is no PreReq on systemd-presets-blabla anywhere :-| -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sat, 05 Apr 2014 12:25:30 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
El 05/04/14 11:37, Jan Engelhardt escribió:
On Saturday 2014-04-05 02:57, Cristian Rodríguez wrote:
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later) [...] Observed problems/gotchas:
zypp installs packages in an unsuitable order
The max-rpm book says that rpm tries to honor "Requires" requests also during installation, but I guess all that prior art is out the window given zypper does one transaction per package :/
Even if zypp did honour this..there is no PreReq on systemd-presets-blabla anywhere :-|
It is required by systemd. So it is always present. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrey Borzenkov wrote:
В Sat, 05 Apr 2014 12:25:30 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
Even if zypp did honour this..there is no PreReq on systemd-presets-blabla anywhere :-|
It is required by systemd. So it is always present.
I can see logrotate having a pre-req on systemd as in the new config, it would need systemd in order for it to run daily, but why would systemd have a pre-req on zypp? Does it call 'zypp' to make changes on your system as part of it's normal function? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sat, 05 Apr 2014 15:44:50 -0700 Linda Walsh <suse@tlinx.org> пишет:
Andrey Borzenkov wrote:
В Sat, 05 Apr 2014 12:25:30 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
Even if zypp did honour this..there is no PreReq on systemd-presets-blabla anywhere :-|
It is required by systemd. So it is always present.
I can see logrotate having a pre-req on systemd as in the new config, it would need systemd in order for it to run daily, but why would systemd have a pre-req on zypp? Does it call 'zypp' to make changes on your system as part of it's normal function?
systemd-presets-blabla, not zypp, is required by systemd. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [2014-04-05 02:57]:
Hi:
Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;)
- Logrotate no longer runs as a cronjob but as a systemd.timer(5)
- You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer
- It continues to run just like "cron.daily" with the following bonus perks:
No it doesn't, right now it is possible to run all the housecleaning in cron.daily at a convenient DAILY_TIME now some jobs do not obey that any more and stuff gets spread out between cron and systemd and each systemd timer has to be configured indiviually.
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
That would be possible with cron using on_ac_power but I don't think it is a good idea to skip rotating logs.
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later)
* If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue:
systemctl status logrotate.service logrotate.timer
That's actually the worst regression of all, if something like logrotate bombs out I want to get notified immediately via email and not have to poll every box, that's insane. This has so severe regressions for no gain at all and should never even have passed Factory review. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 06.04.2014 09:05, schrieb Guido Berhoerster:
* Cristian Rodríguez <crrodriguez@opensuse.org> [2014-04-05 02:57]:
- It continues to run just like "cron.daily" with the following bonus perks:
No it doesn't, right now it is possible to run all the housecleaning in cron.daily at a convenient DAILY_TIME now some jobs do not obey that any more and stuff gets spread out between cron and systemd and each systemd timer has to be configured indiviually.
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
That would be possible with cron using on_ac_power but I don't think it is a good idea to skip rotating logs.
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later)
* If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue:
systemctl status logrotate.service logrotate.timer
That's actually the worst regression of all, if something like logrotate bombs out I want to get notified immediately via email and not have to poll every box, that's insane. This has so severe regressions for no gain at all and should never even have passed Factory review.
When I first read the heads up I was thinking that this makes sense but after some discussion it turned out that important features went away with that. So I'm really wondering to which magnitude we want to allow that all the time? It happened so often in the past and sometimes if we were lucky after quite some time (sometimes years) we were back to feature parity. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 6 Apr 2014 09:05, Guido Berhoerster <gber@...> wrote:
* Cristian Rodríguez <crrodriguez@opensuse.org> [2014-04-05 02:57]: <snip>
- It continues to run just like "cron.daily" with the following bonus perks:
No it doesn't, right now it is possible to run all the housecleaning in cron.daily at a convenient DAILY_TIME now some jobs do not obey that any more and stuff gets spread out between cron and systemd and each systemd timer has to be configured indiviually.
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
That would be possible with cron using on_ac_power but I don't think it is a good idea to skip rotating logs.
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later)
* If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue:
systemctl status logrotate.service logrotate.timer
That's actually the worst regression of all, if something like logrotate bombs out I want to get notified immediately via email and not have to poll every box, that's insane. This has so severe regressions for no gain at all and should never even have passed Factory review.
Even if this gets into Factory as-is, it should NOT made its way into SLE. That would be very bad in any server, and the support would go on strike. Such a change will at best be positiv for a small mobile device (tablet, smart-phone), but will for sure be negativ for any continous ac-powered device. As already said, long fought for behavior options will be lost. This gets (at least as-it-is) a -1 and a FULL-FAIL from me. - Yamaban. PS: to get at least the mail-option back we would need a wrapper script, and thus would be back to the situation of now. Perks? - Do not see any.
El 06/04/14 10:42, Yamaban escribió:
PS: to get at least the mail-option back we would need a wrapper script, and thus would be back to the situation of now. Perks? - Do not see any.
Nah, I will simply revert to the old way and work to make logrotate unnecesary.. ps: http://www.inkcinct.com.au/web-pages/cartoons/past/2007/2007-346-new-technol... -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 06.04.2014 19:22, schrieb Cristian Rodríguez:
ps: http://www.inkcinct.com.au/web-pages/cartoons/past/2007/2007-346-new-technol...
Nice try at ridiculing all the serious users, but what you were presenting were triangular "wheels" at best, without bearings and axles when we had perfecltly round wheels running on ball bearings before ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 06/04/14 19:57, Stefan Seyfried escribió: but what you were
presenting were triangular "wheels" at best, without bearings and axles when we had perfecltly round wheels running on ball bearings before ;-)
The offer is a Ferrari 2015 prototype..but people just want a known, familiar yet faster horse. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 06/04/14 04:05, Guido Berhoerster escribió:
No it doesn't, right now it is possible to run all the housecleaning in cron.daily at a convenient DAILY_TIME now some jobs do not obey that any more and stuff gets spread out between cron and systemd and each systemd timer has to be configured indiviually.
There is no global equivalent to DAILY_TIME in the systemd configuration.. I sincerly hope that idea is not carried forward in time, since I do not believe this is desirable design to follow.
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
That would be possible with cron using on_ac_power but I don't think it is a good idea to skip rotating logs.
run-crons already quits when the system is on battery.. # # Don't run jobs on laptops, that are AC-offline # if test -x /usr/bin/on_ac_power ; then on_ac_power -q if [ "$?" = "1" ]; then exit 0 fi fi
That's actually the worst regression of all, if something like logrotate bombs out I want to get notified immediately via email and not have to poll every box, that's insane.
Since a long time cron no longer requires an SMTP service running on the box and logs to syslog instead.. many people are already not getting email..
This has so severe regressions for no gain at all and should never even have passed Factory review.
Since many upstream projects are slowly moving away from having their own logs to rotate most recently GDM and the X server and instead will start logging to the journal, I will ask for this logrotate change to be reverted and work towards making it unnecessary instead. Next time you see run away cron scripts (yes they escape cron control all the time, try starting a forking daemon from crontab :-D) , hijack port 25.. you will understand why I tried to bring some sanity just to once again hit the wall of tradition. -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [2014-04-06 17:55]:
El 06/04/14 04:05, Guido Berhoerster escribió:
No it doesn't, right now it is possible to run all the housecleaning in cron.daily at a convenient DAILY_TIME now some jobs do not obey that any more and stuff gets spread out between cron and systemd and each systemd timer has to be configured indiviually.
There is no global equivalent to DAILY_TIME in the systemd configuration.. I sincerly hope that idea is not carried forward in time, since I do not believe this is desirable design to follow.
If it wants to replace cron then it should, it is some basic functionality supported by openSUSE and anacron everywhere else. Having housecleaning jobs run at 3:00am when a box is idle is not some strange edge-case that should require admins to edit every single one of these job files just so they run at a certain time in sequence.
That's actually the worst regression of all, if something like logrotate bombs out I want to get notified immediately via email and not have to poll every box, that's insane.
Since a long time cron no longer requires an SMTP service running on the box and logs to syslog instead.. many people are already not getting email..
Sure, and many people don't look at their logs either, but that doesn't mean that it is a good idea and we should make notifications impossible altogether. cron logging to syslog has a valid use-case, e.g. if you have a central syslogserver with nagios monitoring the logs, but for smaller deployments simple mail is the only notification mechanism available.
instead will start logging to the journal, I will ask for this logrotate change to be reverted and work towards making it unnecessary instead.
Thanks, appreciate it.
Next time you see run away cron scripts (yes they escape cron control all the time, try starting a forking daemon from crontab :-D) , hijack port 25.. you will understand why I tried to bring some sanity just to once again hit the wall of tradition.
Filling up your logs isn't ideal either. And apart from getting what you deserve for abusing cronjobs, the effects can in both cases be somewhat mitigated by rate-limiting. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 07/04/14 05:15, Guido Berhoerster escribió:
If it wants to replace cron then it should,
It does not replace cron, but can be used as an alternative to cron, anacron and at. Patches were posted to provide backward compatibility with cron..all were rejected and I hope it stays that way. -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 04, Cristian Rodríguez wrote:
does not get automatically enabled.
While I dont particular care about logrotate, a quick check with logrotate.rpm from 13.1 indicates that it was enabled by default due to the presence of /etc/cron.daily/logrotate. AFAIK cron is enabled by default, so logrotate was up to now enabled per default as well. With logrotate.rpm from Base:System logrotate is not automatically started. How is that supposed to be handled _automatically_ by upgrade or update?
to ensure things keep running smoothly in your factory installation:
$ systemctl enable logrotate.timer $ systemctl start logrotate.timer
Have a lot of fun :-)
We still do, as usual. If arguing is fun... Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 07/04/14 07:28, Olaf Hering escribió:
On Fri, Apr 04, Cristian Rodríguez wrote:
does not get automatically enabled.
While I dont particular care about logrotate, a quick check with logrotate.rpm from 13.1 indicates that it was enabled by default due to the presence of /etc/cron.daily/logrotate. AFAIK cron is enabled by default, so logrotate was up to now enabled per default as well.
With logrotate.rpm from Base:System logrotate is not automatically started. How is that supposed to be handled _automatically_ by upgrade or update?
What is enabled by default is configured by presets. cat /usr/lib/systemd/system-preset/90-default-openSUSE.preset of course the updated preset has to installed *before* the logrotate update, otherwise the call to systemctl preset "$service" in the package's %post scriptlet will do nothing ;) -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Apr 07, Cristian Rodríguez wrote:
What is enabled by default is configured by presets.
cat /usr/lib/systemd/system-preset/90-default-openSUSE.preset
of course the updated preset has to installed *before* the logrotate update, otherwise the call to systemctl preset "$service" in the package's %post scriptlet will do nothing ;)
And, is that done already during upgrade? Or will it be done when people complain? Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 07/04/14 12:26, Olaf Hering escribió:
And, is that done already during upgrade? Or will it be done when people complain?
Apparently it does not work.. maybe adding Requires(pre): systemd-presets-branding to %systemd_requires will be effective.. don't know exactly what zypp does in this case. -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 7 Apr 2014 17:05, Cristian Rodríguez <crrodriguez@...> wrote:
El 07/04/14 07:28, Olaf Hering escribió:
On Fri, Apr 04, Cristian Rodríguez wrote:
does not get automatically enabled.
While I dont particular care about logrotate, a quick check with logrotate.rpm from 13.1 indicates that it was enabled by default due to the presence of /etc/cron.daily/logrotate. AFAIK cron is enabled by default, so logrotate was up to now enabled per default as well.
With logrotate.rpm from Base:System logrotate is not automatically started. How is that supposed to be handled _automatically_ by upgrade or update?
What is enabled by default is configured by presets.
cat /usr/lib/systemd/system-preset/90-default-openSUSE.preset
of course the updated preset has to installed *before* the logrotate update, otherwise the call to systemctl preset "$service" in the package's %post scriptlet will do nothing ;)
If a patch is done for the 'software-management' stack, a special flag is set in the patch, to mark the patch to be installed before the others. Marking the updated systemd-presets the same way should lessen the impact of the logrotate update wrt. to the %post scriptlet. Does RPM / Zypp honor "PreReq:" ? If so, a PreReq: systemd-presets >= {updated-version} would also help. - Yamaban.
В Mon, 7 Apr 2014 17:34:10 +0200 (CEST) Yamaban <foerster@lisas.de> пишет:
Does RPM / Zypp honor "PreReq:" ?
Yes (although modern equivalent is Requires(pre)).
If so, a PreReq: systemd-presets >= {updated-version} would also help.
No. presets are *not* required by RPMs that install services. That would be wrong dependency. Conflicts: presets < {updated-version} is more appropriate but there is no Conflicts(pre) ... I do not think RPM is capable of such finegrained control. Making it work during distribution update would be more than enough. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2014-04-07 19:49, Andrey Borzenkov wrote:
В Mon, 7 Apr 2014 17:34:10 +0200 (CEST) Yamaban <foerster@lisas.de> пишет:
Does RPM / Zypp honor "PreReq:" ?
Yes (although modern equivalent is Requires(pre)).
Requires(pre) means that the dependency is only required for the %pre section. The behavior is not the same as PreReq, which requires the dependency over the entire lifetime, plus it acts as a hint to nudge the dependency order in case of circular deps. IOW, Requires(pre) is not the modern equivalent of PreReq, though Requires(pre) should be sufficient to have in this case of logrotate. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Monday 2014-04-07 19:49, Andrey Borzenkov wrote:
В Mon, 7 Apr 2014 17:34:10 +0200 (CEST) Yamaban <foerster@lisas.de> пишет:
Does RPM / Zypp honor "PreReq:" ?
Yes (although modern equivalent is Requires(pre)).
Requires(pre) means that the dependency is only required for the %pre section. The behavior is not the same as PreReq, which requires the dependency over the entire lifetime, plus it acts as a hint to nudge the dependency order in case of circular deps.
IOW, Requires(pre) is not the modern equivalent of PreReq, though Requires(pre) should be sufficient to have in this case of logrotate.
presets are applied in %post ... Requiring or conflicting with specific versions of the preset package seems odd to me though, There could be multiple different presets packages with different versioning scheme after all. However, even if the updated presets are in place it would still not work as %service_add_post only applies the preset on new installs. So there is code missing that checks which services existed in %pre and applies presets to the new ones in %post. Alternatively the packages could just record the new services and let some post-transaction trigger apply the presets. That would make sure that the new presets are applied if presets were part of the transaction. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 05 April 2014, Cristian Rodríguez wrote:
Hi:
Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;)
- Logrotate no longer runs as a cronjob but as a systemd.timer(5)
- You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer
- It continues to run just like "cron.daily" with the following bonus perks:
So it's still possible to rotate ONLY at a specific time like suse's cron does if you have DAILY_TIME="02:15" in /etc/sysconfig/cron?
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later)
* If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue:
These are again features only useful for laptops or smart phones but not for 24/7 machines. I want log rotation at a specific time when I know they are idle and when no backup is pulled. Please respect above mentioned DAILY_TIME setting for the upgrade scenario.
systemctl status logrotate.service logrotate.timer
Observed problems/gotchas:
zypp installs packages in an unsuitable order, systemd-presets that enable the timer by default may be installed after the logrotate update. thus it does not get automatically enabled.
to ensure things keep running smoothly in your factory installation:
$ systemctl enable logrotate.timer $ systemctl start logrotate.timer
This also needs to be solved for the upgrade scenario.
Have a lot of fun :-)
-- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On 04/04/2014 08:57 PM, Cristian Rodríguez wrote:
Hi:
Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;)
- Logrotate no longer runs as a cronjob but as a systemd.timer(5)
- You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer
- It continues to run just like "cron.daily" with the following bonus perks:
* Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time.
* The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later)
* If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue:
systemctl status logrotate.service logrotate.timer
Observed problems/gotchas:
zypp installs packages in an unsuitable order, systemd-presets that enable the timer by default may be installed after the logrotate update. thus it does not get automatically enabled.
to ensure things keep running smoothly in your factory installation:
$ systemctl enable logrotate.timer $ systemctl start logrotate.timer
Generally I like systemd and the features it provides. However, in this case I have to say that the using systemd puts an additional burden on the users, plus the loss of some features as pointed out in the thread. Just because we can doesn't mean we should. Not everything has to be controlled by systemd or use the features that systemd provides, especially when the changes to base something on systemd implies loss of functionality and additional work for users. We should strive to make things easier for people, not more difficult with more stuff to remember. And maybe the enable command can be inserted in YaST somewhere, but hen this should be an accompanying change. We will get bug reports about this. My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (15)
-
Andrey Borzenkov -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Guido Berhoerster -
Jan Engelhardt -
Linda Walsh -
Ludwig Nussel -
Olaf Hering -
Per Jessen -
Robert Schweikert -
Ruediger Meier -
Stefan Seyfried -
Wolfgang Rosenauer -
Yamaban