From: Christian (chth_at_gmx.net)
Date: Tue 04 Dec 2001 - 22:27:02 GMT
On Tue, 4 Dec 2001 15:59:55 -0500
Jacques Gelinas <jack_at_solucorp.qc.ca> wrote:
> On Tue, 4 Dec 2001 15:47:52 -0500, Christian wrote
> > why not provide a real init to the vserver? that would make rebooting
more
> > sane (we dont need the reboot daemon), the vserver would be more
> > compatible/consistent.
>
> I will experiment running a real init there.
>
> One issue is that orphan process are reparent to process 1. I think this
> is hardcoded in the kernel. Changing this behavior to reparrent to the
> security context 'first process' might make init more standard.
unfortunally the security-context's first process is not 'init' (see
below)
> > how2: store an offset for all pid's of a security-context, so that the
> > vservers init becomes Pid 1 its decendants (and itself). (does this
> > require big kernel changes? i don't assume)
>
> This is also possible.
a grep showed that the kernel uses alot current->pid 's, so its probaby
the easiest to remap the process numbers whenever they are passed between
kernel and userspace, doing it by offsetting all PID's in of security
context will require only a handfull kernel changes: getpid(), kill(),
procfs and the orphaning code mainly.
>
> Having one init per vserver has some advantages
>
> -Makes the runlevel concept available in vservers as well
> -Make inittab respawn process available
>
> It does not make the reboot available. A reboot needs to stop everything
> and start over. The rebootmgr server is still needed to clean up any
> remaining tasks, including the init itself.
ure it does:
from the vserver startup schematic code.. the 'while' needs to be wraped
in a script, targeting 'init' on PID 1 would be the harder task:
<SNIP>
$NICECMD chbind --ip1 $IPROOT --mask1 $IPMASK --net2 $NET2ROOT --mask2
$NET2MASK \
while {
chcontext $CAPS $FLAGS $CTXOPT $HOSTOPT $DOMAINOPT --secure \
save_s_context /var/run/vservers/$1.ctx \
chroot /vservers/$1 /sbin/init #<<< our
init
}; do logger "$1 rebooted"; done
</SNIP>
maybe we could use a patched init (exit 0 for reboot (SIGHUP?) / exit 1
for shutdown (SIGKILL))
i dont know if the real init returns a exit-code, but even a script which
behaves mostely like init will suffice.
What are the implications when we boot a vserver in another order?
chbind->chroot->chcontext->init
solves the pid assignment or?
but can't store the /var/run/vservers/$1.ctx on the parent.. is this a
problem?
cya Christian
PS: what about with my multi-ip patch ... i would like to hear some
comments since i won't work further on it unil i know if it's worth it
(hopefully) ... next step would be to make it possible that vserver
administrators could build sub-vservers to isolate certain services and
constrain their own ip ranges