> On Sun, 03 Feb 2008, Norman Ramsey wrote:
> > However, I do want to make sure bug 459611 is not dropped.
> > I'm sure this won't be the last infinite-loop bug in ghostscript, and
> > as a proper matter of defensive programming, index++ and swish++
> > should protect themselves against such infinite loops---especially
> > since these processes are run periodically as part of other packages
> > (dhelp) and may otherwise take over a user's machine in a most unkind
> > manner.
>
> I agree that periodically run process should run within limits.
>
> index++ and swish++ try to acquire the maximum resource limits that
> are granted to the running process. I suspect this is the source
> of the problem.
>
> Since one cannot (should not?) set arbitrary limits on how long the
> indexing procedure should take what is a reasonable solution to this
> problem?
I believe in defensive programming and also in 'defense in depth'.
Their application in this case suggests that index++ and swish++
should guarantee to terminate even if both parent and child processes
are in error (i.e., parent sets no limits and child runs forever).
> Some possibilities:
> 1. Let the parent process decide on the limits that
> its children should have. In that case these limits
> should be configured by cron which is the calling process.
> Note that cron "knows best" what context it is running in.
> For example, it should be clear that cron.hourly should not
> run for more than an hour, cron.daily for more than a day
> etc.
This is a nice idea. It would be a beautiful thing if index++ could
inspect the process tree and find out if it is being run as part of a
cron job. On many installations it will find a
run-parts .../cron.daily
and it will know. But you can't count on it.
BTW I would argue that cron jobs should not consume more than say 20%
of a machine's resources, so a daily should not take more than 4.8
hours, and hourly should not take more than 12 minutes, etc.
But this could be configurable.
> 2. Have some configuration options for index++/swish++
> which allow the user to set pre-defined limits. Note that
> the user can already do this by setting limits *before*
> calling swish++/index++. Here the burden of deciding the
> context is up to the user.
I don't like this idea at all. swish++ and index++ may be removed
from what the user asked for by several steps of dependencies.
Here's how I would approach the problem:
1. For each type of file index++ understands, you should be able to
estimate the resources index++ needs to index that file. Maybe
you need to get some constant factors at postinst time (perhaps
by looking in /proc/cpuinfo) or maybe not.
2. For each file, index++ should make sure it doesn't use more CPU
than ten times the estimate. If it delegates the indexing to a
child process, it can simply set a suitable limit on the child
process. If it does the indexing itself, it needs to keep an the
clock, e.g., via utimes(2).
3. If time is exhausted, index++ writes an error message into syslog
and moves on to the next file. If stderr is a terminal maybe it
writes the message there as well.
Norman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
