Your message dated Sat, 9 Jan 2010 01:36:24 +0000
with message-id <[email protected]>
and subject line Re: Bug#564154: bad use of process limits when spawning filters
has caused the Debian Bug report #564154,
regarding bad use of process limits when spawning filters
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
564154: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564154
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: xapian-omega
Version: 1.0.7-3+lenny1
Severity: important
omindex fails to index very large document trees due to incorrectly assuming a
filter in not installed half-way through execution.
We're experiencing this when trying to index 2GBs of PDFs, WPDs and DOCs on a
system with 2GB of physical RAM.
This is caused by a ill-conceived idea that setting a memory limit on the
subprocess of 7/8s of "free physical ram" is a good idea in runfilter.cc - this
ultimately results in the filters failing to even start once the limit becomes
too small. As linux aggressively buffers disk pages, using free physical ram
as an indication of available memory results in the system prematurely assuming
it's out of RAM.
Proposed solution is to remove the memory limit completely, or make it a fixed
(configurable) limit.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xapian-omega depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-1.1 GCC support library
ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii libxapian15 1.0.7-4 Search engine library
Versions of packages xapian-omega recommends:
ii apache2 2.2.9-10+lenny6 Apache HTTP Server metapackage
ii apache2-mpm-worker [http 2.2.9-10+lenny6 Apache HTTP Server - high speed th
Versions of packages xapian-omega suggests:
ii antiword 0.37-3 Converts MS Word files to text and
ii catdoc 0.94.2-1 MS-Word to TeX or plain text conve
pn catdvi <none> (no description available)
pn djvulibre-bin <none> (no description available)
ii gs-common 8.62.dfsg.1-3.2lenny1 Dummy package depending on ghostsc
ii libwpd-tools 0.8.14-1 Tools from libwpd for converting W
pn libwps-tools <none> (no description available)
ii poppler-utils [xpd 0.8.7-3 PDF utilitites (based on libpopple
pn unrtf <none> (no description available)
pn unzip <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
fixed 564154 xapian-omega/1.0.17-1
thanks
On Fri, Jan 08, 2010 at 11:19:12AM +1100, Chris Collins wrote:
> This is caused by a ill-conceived idea that setting a memory limit on the
> subprocess of 7/8s of "free physical ram" is a good idea in runfilter.cc -
> this ultimately results in the filters failing to even start once the limit
> becomes too small. As linux aggressively buffers disk pages, using free
> physical ram as an indication of available memory results in the system
> prematurely assuming it's out of RAM.
This was already fixed in 1.0.17-1 - the problem was that the code was using
_SC_AVPHYS_PAGES rather than _SC_PHYS_PAGES:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548987
This fix probably doesn't qualify for a stable update, but you can get fixed
packages for lenny and sarge from the http://backports.org/ repository.
Cheers,
Olly
--- End Message ---
