Re: [naviserver-devel] ns_proxy revisited

[Stephen D. <sd...@gm...>]

On 9/14/06, Zoran Vasiljevic <zv...@ar...> 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...