Re: [Vserver] Small bug report and feature request
On Mon, 31 Jan 2005, Enrico Scholz wrote:
> [EMAIL PROTECTED] (Micah Anderson) writes:
>
> > A small bug report and a feature request:
> >
> > 1. vserver --help shows me:
> >
> > running ... succeeds iff the vserver is running
> >
> > -^^^ should only be one "f" :)
>
> Really? It is meant as
>
> | From The Free On-line Dictionary of Computing (09 FEB 02) [foldoc]:
> |
> | iff
> |
> | if and only if, i.e. necessary and
> | sufficient. For example, two figures are {congruent} iff one
> | can be placed over the other so that they coincide.
However it is certainly not commonly used leading to questions/doubts like
Micah's. It is also overkill to explicitly say "if and only if" when "if
the vserver is running" is sufficiently clear.
the vserver is running"
The following is sufficient:
"'running' will succeed if the vserver is running"
for the help statement. It would be
sufficient to say "running - succeeds if the vserver is running"
is certainly not common amongst those without a mathematics
background
>
>
>
> > Feature request would be to create a vserver remove
> > that properly shuts down the vserver and then removes its
> > configuration and vserver files. I mistakenly removed the
> > files before stopping the vserver last night and it was an
> > interesting adventure to solve that (credit of course goes to
> > Bertl to track down how).
>
> When namespaces are used (that's the default), everything will be
> unmounted after finishing the last process. So executing 'vkill
> --xid -s 9' would have done the trick also. ;)
>
> I will think about the 'vserver ... remove' command.
>
>
>
> Enrico
>
> ___
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
--
Mark Lawrence
+41 79 309 06 33
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Uptime Record?
all, Having just read a post about someone using an older version of the linux-vserver patches I thought it might be interesting to submit the following: [EMAIL PROTECTED]:~/stats$ uname -a Linux xx 2.4.20ctx-17.dlg2 #1 SMP Mon Jun 23 10:03:41 GMT 2003 i686 unknown [EMAIL PROTECTED]/stats$ uptime 12:33:05 up 478 days, 1:01, 2 users, load average: 2.47, 1.99, 2.14 The dlg2 tag on the kernel version refers to a Compaq DL 360 Generation 2 (with 2 CPUs). This box has been in constant production (with three virtual servers) since the last time is was booted and apart from the occasional message regarding unknown TZ values, continues to perform without a hitch. This is more luck than anything else, because the first generation DL360s all had power-supply problems after a year and a half :-) Has anyone run a vserver kernel for longer? For that matter, has anyone run any linux kernel for longer? Regards, Mark. -- Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vshelper works!
On Thu, 26 Feb 2004, Herbert Poetzl wrote: > On Thu, Feb 26, 2004 at 04:16:08PM +0000, Mark Lawrence wrote: > > I've just re-read this, and realised you have not understood my mail on > > this a month ago. My proposed format was (originally s///): > > > > vshelper [] > > > > Where depends on the system call or unique area of request from > > the context. would in fact *not* be "reboot" if vshelper was > > called from somewhere else in the kernel. > > > > If you say that must be one of restart|halt|poweroff... then I > > say that the userspace helper should be called vsreboot and should not be > > used for anything other than responding to sys_reboot. Then we can > > implement another tool for any other userspace interaction. > > two simple questions: > > a) how would a "reboot" "poweroff" be handled differently >in userspace from a "xyz" "poweroff"? "reboot" "poweroff" implies something to do with power in the context of the reboot system call. "xyz" "poweroff" implies something to do with power in the context of the "xyz" system call, but it is only valid to call vshelper with this if it is defined as so. If "xyz" has nothing or knows nothing to do with power then "poweroff" is an invalid argument. > b) wouldn't passing an environmental var, like VS_SYS >with VS_SYS="reboot" be as useful? Why would you want to do that instead of a regular argument? There is in fact already a precedent for calling userspace programs from kernelspace, and that is hotplug. This is a mixture between our viewpoints (first argument is category, actions are passed through environment variables). Perhaps this is the method to follow. I'm not dropping out of this discussion, but I'm on vacation for two weeks and won't be able to reply for a while. Cheers, Mark. -- Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vshelper works!
On Thu, 26 Feb 2004, Herbert Poetzl wrote:
> - char *argv[] = {vshelper_path, id_buf, NULL, NULL, 0};
> + char *argv[] = {vshelper_path, "reboot", id_buf, cmd_buf, 0, 0};
>
> adds a redundant "reboot" argument which doesn't make
> any sense, because everybody knows that restart/halt/etc ...
> is sent from sys_reboot() ... and if it would not be sent
> from sys_reboot() it would also require the redundant
> "reboot" arg to work in userspace, so what's the rationale
> behind that?
>From a discussion at the very beginning, when Paul first wrote schelper we
talked about the context helper tool being called from places in the
kernel other than sys_reboot. If any other use also needs a "restart"
argument you have a clash.
I don't think specific examples were identified, but I could imagine
something like a userspace copy-on-write implementation triggered by
open(2) on a unified context file. Perhaps nothing else would use the
vshelper script, but then why is it not called vsreboot?
> this simply ignores the CAD_ON/OFF messages, which might
> make sense, but which definitely falls exactly in the
> 'unecessarily hide the details of the call' section, you
> claim to avoid ...
I agree - it was a last minute change because I didn't like seeing
multiple messages in my logs.
> using the hex identifier instead of the 'verbose' command
> only makes it more complicated to generate similar messages
> from a different place in the kernel, and it might give
> a difference on different archs where the reboot commands
> are defined differently ... (16/32/64 bit)
ok.
> no problem there, just what is a vshelper good for, when
> the interface was defined in a long and extensive evaluation
> process, and the helper doesn't conform to that interface?
I have missed the evaluation process and can't find the history for it -
did it take place on irc? My apologies again then for re-opening something
which should not have been.
> well, actually I do not care very much, as this vshelper
> interface will go away soon, and it seems that nobody is using
> it at all ...
I must have been sleeping, because this is also news to me. The last post
I can find on this topic is yours from November last year
http://archives.linux-vserver.org/200311/0115.html. There is no mention
that this is an interface that is going away.
I wish I had known, because I would not have put the effort I have into
vshelper... but instead into the new requirement (if any). I believe the
only reason nobody is using the interface is because they didn't have the
tool.
> feel free to branch and/or provide vshelper kernel patches ...
Not my style. However I'll revert to the current kernel interface and put
up a page on the Wiki for those interested.
Cheers, Mark.
--
Mark Lawrence
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vshelper works!
On Thu, 26 Feb 2004, Herbert Poetzl wrote: > adds a redundant "reboot" argument which doesn't make > any sense, because everybody knows that restart/halt/etc ... > is sent from sys_reboot() ... and if it would not be sent > from sys_reboot() it would also require the redundant > "reboot" arg to work in userspace, so what's the rationale > behind that? I've just re-read this, and realised you have not understood my mail on this a month ago. My proposed format was (originally s///): vshelper [] Where depends on the system call or unique area of request from the context. would in fact *not* be "reboot" if vshelper was called from somewhere else in the kernel. If you say that must be one of restart|halt|poweroff... then I say that the userspace helper should be called vsreboot and should not be used for anything other than responding to sys_reboot. Then we can implement another tool for any other userspace interaction. Regards, Mark. -- Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vshelper works!
On Thu, 26 Feb 2004, Herbert Poetzl wrote: > hrm, what do you need the patch for? > > reboot restart > reboot halt > reboot ... > > isn't useful in my opinion Herbert, please re-read my email here: http://list.linux-vserver.org/archive/vserver/msg06152.html where I explained my rational for a change in the interface between kernel and userland for vserver events. The main points were extensibility beyond the reboot function, and to not unecessarily hide the details of the call. I thought I made a reasonable case, but did not hear back from anyone. My fault for assuming silence equals agreement, but I would still appreciate knowing why you think I'm on the wrong track. I'm willing to take my medicine :-) [English expression for having to go though necessary pain] > (you do not want to provide patches for each > vserver kernel patch, and folks do not want to > apply it ;) The patch was for developers to take a look and/or play with. I certainly don't expect people with production systems to go through the effort. My apologies to all if that was how it was taken. Cheers, Mark. -- Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vshelper works!
On Wed, 25 Feb 2004, Mark Lawrence wrote: > Also need to do: > echo "location of vshelper" > /proc/sys/kernel/vshelper I think I also needed to add CAP_SYS_BOOT to the capabilities of the virtual server... Cheers, Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] vshelper works!
On Wed, 11 Feb 2004, Mark Lawrence wrote:
> Therefore I would like to propose the following interface between
> kernel/vshelper.
> vshelper []
...
> vshelper reboot reboot|halt|poweroff|cad_on|cad_off|{restart2 arg}
>
> (actually I would just let the kernel pass the actual hex value of flag).
So I've implemented and tested this, and it works beautifully. From a
virtual server I can now run the native halt or reboot command, which
talks to init via /dev/initctl. Init does its magic and then calls reboot
-f which does the sys_reboot.
sys_reboot calls vshelper with the appropriate arguments and with the
following patch to /usr/sbin/vserver cleans things up. I have no rebootmgr
on the system :)
I therefore submit the following for inclusion...
userspace helper:
http://rekudos.net/download/vshelper-new.
and the following patches to vserver to add "vserver kill" command
and to sys.c (apply over vserver patch) to slighly modify the calling
parameters of vshelper.
Also need to do:
echo "location of vshelper" > /proc/sys/kernel/vshelper
The next step for proper integration would be to change "vserver
stop" and "start" to actually use the init/halt without fiddling
with rc scripts.
Cheers, Mark.
--
Mark Lawrence ([EMAIL PROTECTED])
--- vserver Fri Feb 6 22:10:50 2004
+++ vserver-new Wed Feb 25 21:13:24 2004
@@ -651,6 +651,23 @@
cd /
test -x /etc/vservers/$1.sh && /etc/vservers/$1.sh post-stop $1
ifconfig_iproot_off $1
+elif [ "$2" = "kill" ] ; then
+ echo killing virtual server $1
+ IPROOT=
+ IPROOTMASK=
+ IPROOTBCAST=
+ IPROOTDEV=
+ CAPS=
+ IS_MINIT=
+ readlastconf $1
+ echo Killing all processes
+ $CHBIND_CMD --silent $IPOPT \
+ $CHCONTEXT_CMD $CAPS --secure --silent --ctx
$S_CONTEXT \
+ $VSERVERKILLALL_CMD
+ umountproc $VROOTDIR/$1
+ cd /
+ test -x /etc/vservers/$1.sh && /etc/vservers/$1.sh post-stop $1
+ ifconfig_iproot_off $1
elif [ "$2" = "restart" ] ; then
if $0 $1 running
then
--- sysold.cThu Feb 12 18:42:08 2004
+++ sys.c Wed Feb 25 21:03:33 2004
@@ -286,9 +286,10 @@
* the following arguments
*
* argv [0] = vshelper_path;
- * argv [1] = context identifier
- * argv [2] = "restart", "halt", "poweroff", ...
- * argv [3] = additional argument (restart2)
+ * argv [1] = "reboot"
+ * argv [2] = context identifier
+ * argv [3] = cmd (first argument to this function, as hexidecimal
string)
+ * argv [4] = additional argument (restart2 only)
*
* envp [*] = type-specific parameters
*/
@@ -298,38 +299,28 @@
{
char id_buf[8], cmd_buf[32];
char uid_buf[32], pid_buf[32];
-char buffer[256];
+ char buffer[256];
- char *argv[] = {vshelper_path, id_buf, NULL, NULL, 0};
+ char *argv[] = {vshelper_path, "reboot", id_buf, cmd_buf, 0, 0};
char *envp[] = {"HOME=/", "TERM=linux",
"PATH=/sbin:/usr/sbin:/bin:/usr/bin",
- uid_buf, pid_buf, cmd_buf, 0};
+ uid_buf, pid_buf, 0};
snprintf(id_buf, sizeof(id_buf)-1, "%d", current->vx_id);
+ snprintf(cmd_buf, sizeof(cmd_buf)-1, "0x%08x", cmd);
- snprintf(cmd_buf, sizeof(cmd_buf)-1, "VS_CMD=%08x", cmd);
snprintf(uid_buf, sizeof(uid_buf)-1, "VS_UID=%d", current->uid);
snprintf(pid_buf, sizeof(pid_buf)-1, "VS_PID=%d", current->pid);
-switch (cmd) {
-case LINUX_REBOOT_CMD_RESTART:
- argv[2] = "restart";
- break;
-
- case LINUX_REBOOT_CMD_HALT:
- argv[2] = "halt";
- break;
-
- case LINUX_REBOOT_CMD_POWER_OFF:
- argv[2] = "poweroff";
- break;
-
+ switch (cmd) {
case LINUX_REBOOT_CMD_RESTART2:
if (strncpy_from_user(&buffer[0], (char *)arg,
sizeof(buffer) - 1) < 0)
return -EFAULT;
argv[3] = buffer;
+ case LINUX_REBOOT_CMD_CAD_ON:
+ case LINUX_REBOOT_CMD_CAD_OFF:
+ return 0
default:
- argv[2] = "restart2";
break;
}
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Better network support
On Thu, 19 Feb 2004, Thomas Gelf wrote: > we have done many changes to debian-newvserver, adding static > context ids, per context disk limits, a little fix regarding > network configuration to match our "bridged-dummy"-solution > and so on. at the moment the code is very strictly bound to our > situation here - I'll post it, if it has become more configurable. Hi Thomas, I would be keen to do an update to the newvserver script. If you don't mind sending me the changes you have made, regardless of the state they are in, I will make an effort to include as relevant... Cheers, Mark. -- Mark Lawrence ([EMAIL PROTECTED]) ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: [pre-release] vshelper
On Tue, 10 Feb 2004, Mark Lawrence wrote:
> I have written an alpha-quality (untested) version of the vshelper script
> (and accompanying manpage) which I would like to invite discussion on. It
> does not actually do anything at the moment because it requires the
> vserver(8) script to be patched with a new "kill" command.
So, I hacked on the script a bit more, and found a system to test it on.
The results surprised me a bit, and I'd like to make the following
comments with regards to the interface between the kernel and userland.
The kernel patch to reboot(2) invokes the vshelper script with the
following syntax:
vshelper restart|halt|poweroff|restart2 [arg]
My first comment about this is that it is only suitable for use for reboot
related activities, and can't be nicely extended. Although I don't have
any examples, I thought that vshelper would be intended as a a more
generic tool.
So I put the script location into /proc/sys/kernel/vshelper and called
halt(1) from a context. The following showed up in the syslog:
Feb 10 19:24:07 hsee-tor-s001 logger: reboot(restart2) ctx 3 (unknown), uid 0, pid
508, arg
Feb 10 19:24:07 hsee-tor-s001 logger: reboot(halt) ctx 3 (unknown), uid 0, pid 508, arg
Feb 10 19:24:07 hsee-tor-s001 logger: reboot(restart2) ctx 3 (unknown), uid 0, pid
508, arg
No I did not call halt or restart three times. It turns out that the
sysvinit utilities (halt, reboot etc) make several calls to reboot(2).
The first changes the Ctl-Alt-Del setting (flag LINUX_REBOOT_CMD_CAD_ON).
Then it calls reboot(2) to actually halt (flag LINUX_REBOOT_CMD_HALT). The
third call (flag ...RESTART2) is actually a fall-through because normally
the CMD_HALT would not return.
What I find misleading, is that the current vserver-reboot(2) patch makes
a distiction between restart, poweroff, halt and restart2, but not the
other two possibilites CAD_ON and CAD_OFF. In fact it kind of puts the
last two flags into the RESTART2 category.
I would prefer that vshelper be the true user-space policy implementation
of reboot(2), and be given a clearer message of what the context
requested.
Therefore I would like to propose the following interface between
kernel/vshelper.
vshelper []
Where depends on the system call or unique area of request from
the context. is of course the context, and are zero or more
arguments which are specific to the .
Hence for reboot we would have in the generic sense:
vshelper reboot [arg]
which in the specific sense would be:
vshelper reboot reboot|halt|poweroff|cad_on|cad_off|{restart2 arg}
(actually I would just let the kernel pass the actual hex value of flag).
As you can see this is much closer to the original system call, and lets
us better define policy in userland. Maybe one day we want to perform an
action when CAD_ON or CAD_OFF are called? However calling vshelper with
"restart2" to do that is not very obvious.
I have also put together a script which implements this syntax (but no
man-page yet) at http://rekudos.net/download/vshelper-new.
Once again feedback is welcome...
Cheers, Mark.
--
Mark Lawrence
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] [pre-release] vshelper
Hi all, This is mostly for Herbert, Enrico and those who like to live on the edge. There has been a functionality in the vserver patch for some time, to allow the kernel to call a program when a process in a context (other than context zero or one) calls reboot(2). The program called by the kernel does for the virtual server what would appear to be the 'hardware' functions of halting or rebooting. This is already handled somewhat inelegantly by the rebootmgr daemon. Rebootmgr creates sockets in each vserver, and listens to requests from specially installed reboot/halt commands in the virtual servers. The advantage of vshelper is that it is light-weight (only runs when vservers want to reboot), and means that the original distribution reboot/halt utilities can be used transparently as if you were running on hardware. I have written an alpha-quality (untested) version of the vshelper script (and accompanying manpage) which I would like to invite discussion on. It does not actually do anything at the moment because it requires the vserver(8) script to be patched with a new "kill" command. However I would like to see it replace the rebootmgr daemon in future releases and would seek your feedback on what it needs to do so. http://rekudos.net/download/vshelper # script http://rekudos.net/download/vshelper.8 # manpage Cheers, Mark. -- Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] No network response, until outgoing packet sent
Hi all, I have just built a brand new machine with the latest in stable vserver setup, but am observing some strange behaviour. IBM server Xeon(TM) CPU Fusion MPT SCSI Host driver 2.05.05+ eth0: Tigon3 [rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT eth1: Tigon3 [rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Debian woody gcc version 2.95.4 20011002 (Debian prerelease) linux-2.4.24 patch-2.4.24-vs1.24.diff util-vserver-0.27 I patched, configured, built, installed the kernel and rebooted. Machine comes up fine, configures the ethernet interface like normal and shows no obvious signs of error. However the box is unreachable from the network, until after packets are sent out of the ethernet interface. So far I have only tested this with icmp. Basic tests with chbind, chcontext etc work fine afterwards. I vaguely remember something like this being seen before, but can't find the relevant discussion. Can someone first of all point me in that direction, and/or comment on what I can troubleshoot to provide more information? Regards, -- Mark Lawrence ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
RE: [vserver] Copying vservers
I fixed the ownership problem some time ago. I even posted the code to the
list and/or the tool maintainers but I guess it got lost... Perhaps
Roderick can tell us where he obtained the script from?
I have attached my latest copy plus the *man* page which gives an example
of how to copy from one host to another. As others have pointed out there
are other ways to do it manually, however I suggest that to make life easy
for newcomers it is worth having a documented tool.
Cheers,
Mark.
On Fri, 5 Dec 2003 [EMAIL PROTECTED] wrote:
> hi,
>
> rsync won`t help because the userrights (direcotry specially) eventuelly get
> wrong, if i copy from hostmachine to hostmachine.
>
>
> I have no idea how to copy "correctly" between two server.
>
>
> Greetings
> Oliver
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Roderick A.
> Anderson
> Sent: Freitag, 5. Dezember 2003 19:57
> To: [EMAIL PROTECTED]
> Subject: Re: [vserver] Copying vservers
>
>
> I have a request for Mark Lawrence. I've looked at and wanted to use the
> vserver-copy script you wrote but it doesn't quite (or at least doesn't
> appear to) do a copy from one partition to another. I have very little
> experience with rsync so hesitate to fiddle with it.
>
>
> Best,
> Rod
> --
> "Open Source Software - You usually get more than you pay for..."
> "Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL"
>
>
> ___
> Vserver mailing list
> [EMAIL PROTECTED]
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
>
> ___
> Vserver mailing list
> [EMAIL PROTECTED]
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
#!/bin/sh
#
# Copyright (C) 2002, Mark Lawrence <[EMAIL PROTECTED]>.
# Licence: GPL
#
# Copy/Sync a virtual host from one machine to another
#
# History:
#
# 2003-02-23: Version 0.2 - Mark Lawrence
# - Set ONBOOT to "no" in the original .conf file when the "-s" flag is
# used so that if/when you reboot the source roothost you don't have the
# same vserver and IP address running on two machines.
#
# 2003-03-04: Version 0.3 - Mark lawrence
# - Changed all checks for [ "" != "$var" ] into [ -n|-z "$var" ]. "" doesn't
# seem to work for bash on the Sparc architecture.
# - Changed $ssh variable into $shcmd.
#
# 2003-04-04: Version 0.4 - Mark lawrence
# - Set "ONBOOT=no" in the destination .conf file when --startstop
# is not used, in case the destination roothost reboots. We don't
# want two copies of a vserver running at the same time.
#
# 2003-06-24: Version 0.5 - Mark lawrence
# - Added --numeric-ids to the main rsync call, because
# otherwise the uids could be translated/change during the copy.
# - Aadded --delete to the main rsync call because I found out the
# hard way that things like mail queue files would always grow.
# Ie: mails in the queue are copied, and will be delivered again if
# you backup from the copy, or start the copy of the vserver on another
# machine.
VERSION="0.5"
umask 022
me=${0##*/}
### Helper functions ###
# Save stdin and stdout for later use
exec 3>&1
exec 4>&2
noninteractive () {
exec &> /dev/null
}
interactive () {
exec 1>&3
exec 2>&4
}
info () {
! $quiet && echo "I: $me: $1" >&3
}
warn () {
! $quiet && echo "W: $me: $1" >&4
}
error () {
! $quiet && echo "E: $me: $2" >&4
rm -f $tmpf
exit $1
}
### Usage/Info functions ###
usage () {
cat <&2
Usage: $me [-hVvqidrRs] vserver newname
$me [-hVvqidrRs] vserver host:[newname]
(Use -h for help)
EOF
}
full_usage () {
usage
cat <
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.
EOF
}
### Default values and Command line options ###
stopstart=(false)
verbose=(false)
quiet=(false)
shcmd="ssh"
rsflag="-e"
rsh=(false)
colon=":"
domain=""
ip=""
vsroot="/vservers"
if [ $# -eq 0 ]; then # Script invoked with no command-line args?
usage
exit 1
fi
temp=$(getopt -o hVvqd:i:rRs --long
help,version,verbose,quiet,domain:,ip:,vsroot,rsh,stopstart, -n $me -- "$@")
if [ $? -ne 0 ]; then
echo " (See -h for help)"
exit 1
fi
# Note the quotes around `$temp': they are essential!
eva
Re: [Vserver] hrm... another odd thing.. /dev/initctl?
On Mon, 17 Nov 2003, Enrico Scholz wrote: > > that would do a context id check (ie where's it coming from and what's > > it trying to apply those changes to) and then if everything checks out, > > does the vserver start/stop/restart. > > How will you do this resolving for vserver-in-a-vserver? When we get to the stage where nested vservers are possible, I'm sure it will be a relatively simple kernel task to send the event to the correct context. Some structure within the kernel will need to know parent/child context relationships anyway. Mark. ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] netstat Oopsing 2.4.23-rc1
On Mon, 17 Nov 2003, Matt Ayres wrote: > You're correct, we observed the same thing. The CPU/Load is caused by > kswapd. Errors exactly like this has been reported for 2.4.2 and 2.4.9 > (that we can find), so perhaps one of the bugs re-surfaced in 2.4.2X. After a bit of hunting I also found the following threads describing similar issues (not with kswapd but with un-freed buffers) with as recent a kernel as 2.4.22-pre5: http://lists.insecure.org/lists/linux-kernel/2003/Jul/5835.html http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1980.html > I've just got finished a working port of vserver under UML (very cool!). groovy! Mark. -- ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
