So, two questions: 1) my Z2.log is growing continuously, and that would not be strictly a problem; but now it's 1.3Gb.. and i can expect him to grow more and more... My ambition is not to full entire disk space for the logs, but as i know, i can't avoid to keep them! The content of Z2.log is plain text, and i can suppose that using some sort of compression method probably might lead to an high rate compression of Z2.log. It would be great if Medusa could handle compressed Z2.log. Is there a way to accomplish this? 2) In Zope v. >= 2.6.0 has been implemented this nice feature: "Gzip content compression when serving pages" (http://www.zope.org/Products/Zope/2.6.0/announce) It's supposed that gzip feature is enabled by default; well, how to obtain statistic about compression?(i.e. size of html page after compression, maybe the ratio and so on...) With mod_gzip for Apache there was the possibility to specify something like: LogFormat "%h %l %u %t \"%r\" %>s %b mod_gzip: %{mod_gzip_result}n In:%{mod_gzip_input_size}n Out:%{mod_gzip_output_size}n:%{mod_gzip_compression_ratio}npct." common_with_mod_gzip_info2 and CustomLog /usr/local/apache/logs/access.log common_with_mod_gzip_info2 Does Medusa allow something similar? Thanks all, Paolo Dina
Paolo Dina wrote at 2003-7-7 09:37 +0200:
1) my Z2.log is growing continuously, and that would not be strictly a problem; but now it's 1.3Gb.. and i can expect him to grow more and more... My ambition is not to full entire disk space for the logs, but as i know, i can't avoid to keep them! The content of Z2.log is plain text, and i can suppose that using some sort of compression method probably might lead to an high rate compression of Z2.log. It would be great if Medusa could handle compressed Z2.log.
When you sent a Zope process a "SIGUSR2" signal, it closes and reopens all its log files. You can use this for log rotation. E.g. mv Z2.log Z2.log.save kill -SIGUSR2 $(cat var/Z2.pid) # this will close the old log file and open a new one Now, you can compress "Z2.log.save" (or delete it). Dieter
I recently put added the cookiecrumbler to my root folder and attempted to manage my logins through the included forms. When I modified one of the forms and saved it with a typo in it, the login_form action no longer logged the user in. When I tried to get to the /manage screen, i was prompted wih the same botched login_form screen and could not log in as the owner to correct the typo. Luckily, on another machine, I had a session still open to the manage screen from yesterday, so i was able to go in and correct the issue. My question is this: If I didn't have an open session, how could I have corrected the problem? Thanks, Ben On Mon, 7 Jul 2003, Dieter Maurer wrote:
Paolo Dina wrote at 2003-7-7 09:37 +0200:
1) my Z2.log is growing continuously, and that would not be strictly a problem; but now it's 1.3Gb.. and i can expect him to grow more and more... My ambition is not to full entire disk space for the logs, but as i know, i can't avoid to keep them! The content of Z2.log is plain text, and i can suppose that using some sort of compression method probably might lead to an high rate compression of Z2.log. It would be great if Medusa could handle compressed Z2.log.
When you sent a Zope process a "SIGUSR2" signal, it closes and reopens all its log files.
You can use this for log rotation. E.g.
mv Z2.log Z2.log.save kill -SIGUSR2 $(cat var/Z2.pid) # this will close the old log file and open a new one
Now, you can compress "Z2.log.save" (or delete it).
Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, July 8, 2003, at 04:30 AM, Ben Schy wrote:
I recently put added the cookiecrumbler to my root folder and attempted to manage my logins through the included forms. When I modified one of the forms and saved it with a typo in it, the login_form action no longer logged the user in. When I tried to get to the /manage screen, i was prompted wih the same botched login_form screen and could not log in as the owner to correct the typo. Luckily, on another machine, I had a session still open to the manage screen from yesterday, so i was able to go in and correct the issue. My question is this: If I didn't have an open session, how could I have corrected the problem?
By reading the README.txt file in the Cookie Crumbler distribution that explains how to do it? - -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/Cl9+h8iUz1x5geARAmEPAKDWjjCRqojeaIkaQ29lb5udrbm8TwCffe9q cKpMmdGHgMoMxGZi52Pv5rA= =5NSC -----END PGP SIGNATURE-----
Dieter Maurer wrote:
When you sent a Zope process a "SIGUSR2" signal, it closes and reopens all its log files.
You can use this for log rotation. E.g.
mv Z2.log Z2.log.save kill -SIGUSR2 $(cat var/Z2.pid) # this will close the old log file and open a new one
Great solution :) Only one precisation: that method does not work on Zope 2.5.1, in which case, the log is recreated, but Zope doesn't restart automatically. All is ok with version 2.6.1.
Now, you can compress "Z2.log.save" (or delete it).
And then, for log rotation probably i will use logrotate utility. Thankyou Dieter.
Dieter
Paolo
participants (4)
-
Ben Schy -
Dieter Maurer -
Paolo Dina -
Stuart Bishop