Bug#344481: marked as done (php4-rrdtool: Use of RRD extensions (graph only?) causes Apache to segfault)
Your message dated Sun, 13 May 2007 14:14:57 +0200 with message-id [EMAIL PROTECTED] and subject line This bug is no longer valid has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: php4-rrdtool Version: 1.04-15 Severity: important I have a horrible feeling this is just me, because I can't believe no-one else is experiencing it... Any use of the RRD extensions since 1.04-15 in PHP4 by my scripts causes the apache sub-processes to immediately segfault, before anything is even logged to the access.log. All I get is repetitions of: [Mon Sep 26 18:31:49 2005] [notice] child pid 19613 exit signal Segmentation fault (11) [Mon Sep 26 18:31:49 2005] [notice] child pid 19614 exit signal Segmentation fault (11) [Mon Sep 26 18:31:49 2005] [notice] child pid 19620 exit signal Segmentation fault (11) ...in /var/log/apache/error.log, and Zero Sized Reply to my requests. I'm sorry this isn't a very complete bug report, but since it's breaking the package (for me at least), I thought I'd better report it anyway. There's nothing in the changelog, FAQ or README to point out where I might be awry. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable'), (500, 'testing'), (200, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.200506221 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Versions of packages php4-rrdtool depends on: ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy ii libapache-mod-php4 [phpapi-20 4:4.4.0-2 server-side, HTML-embedded scripti ii libc6 2.3.5-6GNU C Library: Shared libraries an ii librrd2 1.2.11-0.4 Time-series data storage and displ ii php4-cgi [phpapi-20050606]4:4.4.0-2 server-side, HTML-embedded scripti ii php4-cli [phpapi-20050606]4:4.4.0-2 command-line interpreter for the p php4-rrdtool recommends no packages. -- debconf information: php4/add_extension: true * php4/extension_rrdtool_apache: true php4/remove_extension: true * php4/extension_rrdtool_cgi: true * php4/extension_rrdtool_cli: true ---End Message--- ---BeginMessage--- Hi, The php4-rrdtool has been scheduled for removal from Debian. So, #330197 and this bug are no longer valid. Regards Artur -- Promotor polecił mi, żebym przy opisie wzorów podtrzymywania swojego statusu przez adminów korzystała z książki opisującej analogiczne procesy... w więzieniu i wśród młodocianych przestępców. :) /Socjonetka/ ---End Message---
Bug#423638: apache2.2-common: a2enmod uses relative path instead of absolute
Package: apache2.2-common Version: 2.2.3-4 Severity: Minor The shell script `a2enmod` uses a relative path instead of an absolute path when enabling modules. This is minor security concern as it could cause any potential problems whilst running Apache by allowing path traversal. The following patch to fix the problem is included: --- a2enmod 2007-05-13 10:46:21.0 -0400 +++ a2enmod.new 2007-05-13 10:46:42.0 -0400 @@ -43,7 +43,7 @@ for i in conf load; do if [ -e $SYSCONFDIR/mods-available/$MODNAME.$i -a ! -e $SYSCONFDIR/mods-enabled/$MODNAME.$i ]; then cd $SYSCONFDIR/mods-enabled; -ln -sf ../mods-available/$MODNAME.$i $MODNAME.$i; +ln -sf $SYSCONFDIR/mods-available/$MODNAME.$i $MODNAME.$i; fi done As I said, this is a minor issue and probably trivial but I'm rather uncomfortable with the fact that it uses a relative path rather than an absolute one like a2ensite. -- 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
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]
Processed: [bts-link] source package apache2
Processing commands for [EMAIL PROTECTED]: # # bts-link upstream status pull for source package apache2 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). # remote status report for #235653 # * http://issues.apache.org/bugzilla/show_bug.cgi?id=18712 # * remote status changed: (?) - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 235653 + fixed-upstream Bug#235653: No ssl/tls support in mod_auth_ldap and mod_ldap There were no tags set. Tags added: fixed-upstream usertags 235653 + status-RESOLVED resolution-FIXED Bug#235653: No ssl/tls support in mod_auth_ldap and mod_ldap There were no usertags set. Usertags are now: resolution-FIXED status-RESOLVED. # remote status report for #393646 # * http://issues.apache.org/bugzilla/show_bug.cgi?id=40781 # * remote status changed: (?) - NEW usertags 393646 + status-NEW Bug#393646: PATH_TRANSLATED: 'redirect:/~jablko/gallery2/main.php' There were no usertags set. Usertags are now: status-NEW. # remote status report for #414855 # * http://issues.apache.org/bugzilla/show_bug.cgi?id=37911 # * remote status changed: (?) - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 414855 + fixed-upstream Bug#414855: wildcard cert not working in apache 2.2 Tags were: patch Tags added: fixed-upstream usertags 414855 + status-RESOLVED resolution-FIXED Bug#414855: wildcard cert not working in apache 2.2 There were no usertags set. Usertags are now: resolution-FIXED status-RESOLVED. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[bts-link] source package apache2
# # bts-link upstream status pull for source package apache2 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #235653 # * http://issues.apache.org/bugzilla/show_bug.cgi?id=18712 # * remote status changed: (?) - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 235653 + fixed-upstream usertags 235653 + status-RESOLVED resolution-FIXED # remote status report for #393646 # * http://issues.apache.org/bugzilla/show_bug.cgi?id=40781 # * remote status changed: (?) - NEW usertags 393646 + status-NEW # remote status report for #414855 # * http://issues.apache.org/bugzilla/show_bug.cgi?id=37911 # * remote status changed: (?) - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 414855 + fixed-upstream usertags 414855 + status-RESOLVED resolution-FIXED thanks
Bug#400455: reproduced
Hi, I'm seeing this on moderately loaded servers. It exists both in sarge and etch, apparently. :( -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423638: apache2.2-common: a2enmod uses relative path instead of absolute
[Alan LeVee] The shell script `a2enmod` uses a relative path instead of an absolute path when enabling modules. This is minor security concern as it could cause any potential problems whilst running Apache by allowing path traversal. I can understand the aesthetic desire for a2ensite and a2enmod to do the same thing, but I don't understand your security concerns. There is simply no way a relative link to ../mods-available/foo.load is ever going to behave differently than an absolute link to /etc/apache2/mods-available/foo.load. So this is a purely aesthetic issue - or am I missing something? signature.asc Description: Digital signature
Bug#423653: apache2.2-common: mod_disk_cache fills /var after etch upgrade
[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. 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.) 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. 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. 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. Thanks, Peter signature.asc Description: Digital signature
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]
