About this list Date view Thread view Subject view Author view Attachment view

From: Alex Lyashkov (shadow_at_psoft.net)
Date: Sat 24 May 2003 - 15:11:36 BST


On Monday 19 May 2003 10:50, Herbert Poetzl wrote:
> Sorry Alex!
>
not problem :)

> >
> > trivial.
> > It's need add new command in new_s_context syscall.
> > "stop_vserver".
> > My patch have list all process in context.
> > code for this simular:
> >
> > write_lock(&task_lock); // exclusive blocking.
> > for_each_task_in_context(ctx,tsk)
> > {
> > task_t *task = tsk->task;
> > force_sig(SIGKILL,task); // or SIGTERM
> > }
> > write_unlock(&task_lock);
> > and block creating new process in context.
> >
> > correctly ?
>
> sounds good ...
>
> I had some thought on this issue, and I guess it would
> be the best solution, to freeze all processes (not
> with SIG_STOP but) by NOT scheduling any of the vserver
> tasks anymore? why?
freezing add _NEW_ processes in context - old process scheduling as usually.
You scripts have many childrens and more simply kills all process and restart
vps. But if you block add new processes in context you script stoped himself.

>
> - you could have a good look at the processes from
> outside (couldn't you?)
not. i don't see process outside vps. it`s kernel work.

> - you probably could send any signal from ctx-1 or
> from vserver <ctx> enter? (am I wrong?)
not. from tools vserver_ctl.
run example:
 vserver_ctl -x 4 stop sendsig sigkill
but it's need restart vps.

> - after unfreezing SIG_KILL signalled processes, it
> should have the same effect as the kernel loop
> above (shouldn't it?)

-- 
With best regards,
Alex


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sat 24 May 2003 - 15:44:45 BST by hypermail 2.1.3