On 9/14/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 14.09.2006, at 21:46, Stephen Deasey wrote:
> What are your rules for checking for a long running process?
>
> If the ns_proxy command is for isolating badly behaved code, it seems
> to me there could usefully be a few more built in checks for bad
> behaviour, rather than having to implement these checks manually.
True.
>
> For example, how about a switch which defines the maximum running time
> for the command? You can handle this now as Zoran points out by
> waiting for the result with a timeout. But this is awkward to handle
> if you have a 'detached' proxy job.
This can be done "indirectly":
set milliseconds 2000
set p [ns_proxy send $p some_broken_hanging_script]
if {[catch {ns_proxy wait $p $milliseconds}]} {
ns_proxy put $p
}
Put it in a procedure and there you go.
But now the initiating thread is tied up with an idle wait -- i.e. you
can't intiate the job and have it run in the background. This
issolates the code externaly, but it requires resources (a thread) for
each job you start.
The ns_job command can handle detached jobs.
>
> Explicitly passing the runtime-timeout would also eliminate some race
> conditions. Let's say you start a job, then in some other thread get a
> list of jobs including pid, figure out a job has taken too long, then
> kill the pid. The job could exit between the time you get the pid and
> the time your decide to kill it. Pid's recycle (eventualy), and you
> kill some completely unrelated proces.
Heh... bad cruel world... but it isnt really that black really.
Normally the pid wrapup should take some time...
>
> Runtime limits could be implemented with a timer and signal handler in
> the proxy process.
Or as above.
>
> One common bad behaviour other than lack of thread safety is memory
> leaks. How about some switches which set rlimits for the process,
> maximum heap memory and such? This would also be a nice safety
> feature -- say you're converting images or movies uploaded by some
> untrusted source and you want to ensure a flaw in your converter
> library doesn't compromise your server.
>
> Maybe a chroot switch would be useful?
>
Yes! All this could be really useful. The only trouble is
the syntax. How to pass this to the new process?
Over the cmd line? Env array? Store this per pool (most probably)?
Per-pool, I guess, at least for hard limits. Otherwise each proxy
could only handle one job. You could get fancy and re-set soft limits
for each job, for some proxy pool for general jobs, but that sounds
like version 2...
