Bug#423653: apache2.2-common: mod_disk_cache fills /var after etch upgrade
Package: apache2.2-common Version: 2.2.3-4 Severity: critical Justification: breaks unrelated software After an upgrade to etch, mod_disk_cache started storing things in /var/cache/apache2/mod_disk_cache, without any apparently limit on size. This caused /var to fill up, which had bad effects on the entire system. I am not sure if mod_disk_cache was enabled or not before the upgrade to etch (from sarge), but it was certainly not using disk space in the same way. The problem appears to be related to having mod_proxy enabled at upgrade time, according to bug #407171 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407171) It is not entirely clear to me from that bug description whether mod_disk_cache was previously enabled but in a different way, or if it is newly enabled by the upgrade. mod_disk_cache appears to be experimental (http://httpd.apache.org/docs/2.0/mod/mod_disk_cache.html), and also the "garbage collection" features that would be necesary to keep the disk cache to a fixed bound are not yet implemented. Disabling it seems not to have caused any problems, even for mod_proxy. Someone else seems to have noticed this problem too: http://tumbleweed.org.za/2007/05/04/sarge-etch-upgrade-and-apache2/ -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (600, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages apache2.2-common depends on: ii apache2-utils2.2.3-4 utility programs for webservers ii libmagic14.17-5etch1 File type determination library us ii lsb-base 3.1-23.1Linux Standard Base 3.1 init scrip ii mime-support 3.39-1 MIME files 'mime.types' & 'mailcap ii net-tools1.60-17 The NET-3 networking toolkit ii procps 1:3.2.7-3 /proc file system utilities apache2.2-common recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423653: apache2.2-common: mod_disk_cache fills /var after etch upgrade
On Mon, 14 May 2007, Peter Samuelson wrote: [Ganesh Sittampalam] I am not sure if mod_disk_cache was enabled or not before the upgrade to etch (from sarge), but it was certainly not using disk space in the same way. In the sarge packages, /etc/apache2/mods-available/proxy.load includes four modules: mod_cache, mod_disk_cache, mod_proxy, mod_proxy_http. These have been separated in the etch packages, so the upgrade procedure checks to see whether you had mod_proxy enabled before, and if so, it enables all 4 modules. OK. I do not know why the sarge version of mod_disk_cache did not fill up your disks, unless it is due to the CacheSize configuration setting, but the docs imply that that setting didn't actually work. (It has since been removed from the module.) As far as I could gather from looking at timestamps when I first noticed the problem, the /var/cache/apache2/mod_disk_cache directory was first created during or after the etch upgrade. mod_disk_cache appears to be experimental (http://httpd.apache.org/docs/2.0/mod/mod_disk_cache.html) It was, in Apache 2.0. Etch ships with Apache 2.2; if you read http://httpd.apache.org/docs/2.2/mod/mod_disk_cache.html you will see that it is no longer experimental. Oops, apologies for that. You'll also see that the developers chose not to implement the garbage collection within the module, but as an external utility "htcacheclean" which can either be run periodically from cron, or run as a daemon that wakes itself up on occasion. Right, that sounds reasonable. Arguably we should be starting this daemon automatically. We don't, currently, but unless you have a better idea, I think I will implement this in /etc/init.d/apache2, with options in /etc/default/apache2 to determine whether it is needed and how big the cache show be allowed to grow. That sounds reasonable. I don't know what a good default for the size would be, though; to avoid causing trouble on small systems it would need to be <100MB, but this may make the cache ineffective. Thanks, Ganesh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
