Hello,
On Mon, 16 Jun 2008, Pawel Wiecek wrote:
> I've been hit by this bug as well and would like to add a bit of
> clarification: these processes are not zombies -- they are _running_:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 19691 root 20 0 32456 3652 1164 R 100 0.2 56:18.35 index++
>
> As originally reported they are 100% immune to killing, I can kill -9 the
> process and it's still there (same PID, so it's not restarted by anything).
Once you have killed the process it is not really using anything
except possibly keeping some swap space tied up.
> I believe wishlist priority for this bug is not justified, while playing with
> resource limits might workaround it, it would not solve the real bug.
The reasons for tagging the bug wontfix and using the wishlist severity
are as follows:
1. The upstream author does not consider this as a bug in the program.
2. The problem is with the way index++ is invoked by a cron job which
in turn is installed by "dwww" and not by "swish++". As a crude
example, you could start a cron job invoking the script
#!/bin/sh
while true do
{put any time consuming program here}
sleep 1
done
This may eat up some resources but you could not count it as a bug in
"/bin/sh".
3. The problem is that the default configuration for "swish++"
cannot anticipate all the different contexts in which it is run.
(a) Someone running an indexing service for a library may not
want to limit resources and will be happy if the job takes
a week but produces a complete index.
(b) On the other hand someone wanting to setup an index for
e-mail may not want to wait that long.
4. The best that can be done is to:
(a) Provide sample configuration files for low-resource
usage.
(b) For "cron" to apply resource limits to the jobs it
starts.
None of the above can "solve" the original bug. So that explains the
"wontfix" tag. Since the bug is a request for a new feature
(alternate config files) while the original package remains
completely usablee it is severity wishlist.
Regards,
Kapil.
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
