Hello,
First up, is the mailing list still working? Maybe I am no longer
subscribed because I haven't received anything today...
1) I have an idea with regards the current method of rebooting/halting
virtual servers. Presently a virtual server must be modified (installation
of the vreboot command) in order to be able to inform the root server that
it should be rebooted. This requires the modification of init.d/rc.d
scripts or knowledge by the vserver sysadmin plus an extra rebootmgr demon
in the root server to listen for reboot requests. I think this can be
simplified so that the behaviour is more streamlined/natural.
During a normal halt or reboot process, init or some rc script ends up
executing /sbin/reboot which calls the reboot(2) system call. Currently
this is ignored unless CAP_SYS_REBOOT is defined. I propose that instead
of ignoring the reboot(2) call the kernel spawns a "vserver <context>
stop|start|restart" in context 1. This way, the real /sbin/reboot can be
called as normal without having to be replaced by vreboot, and we do away
with the need for rebootmgr in the root server. Apart from the kernel
change I think this would need the vserver script to handle a "restart"
option and to take a context as an option as well as the virtual server
name. Does this seem workable?
2) I also have a small patch for the /usr/sbin/vserver script. "running"
and "status" both count how many processes are running by entering the
security context:
NB=`$CHCONTEXT_CMD --silent --ctx $S_CONTEXT ps ax | wc -l`
NB=`eval expr $NB + 0`
This is inaccurate in the case of the "status" command because we have
added three processes to the context just to make the measurement. It also
fails on the "running" case when there is only one process left (ie after
doing a "init 0" in a fakeinit server for example). What I suggest is that
the above is replaced with:
NB=$(vps ax | awk '{print $2}' | grep $S_CONTEXT | wc -l)
which is more accurate.
Cheers,
Mark.
--
[EMAIL PROTECTED]
