From: Lars Braeuer (lbraeuer_at_mpex.net)
Date: Thu 12 Sep 2002 - 15:31:34 BST
Per R Laursen wrote:
> On Thursday 12 September 2002 15:07, you wrote:
>
>>do you have anything entered in the /etc/vserver/v1.sh file?
>>What's the output right after you entered vserver v1 start on the
>>command line?
>>
>>I get something like:
>>Starting the virtual server jco1
>>Server jco1 is not running
>>ipv4root is now 80.239.136.143
>>Host name is now jco.mpex.net
>>Domain name is now
>>New security context is 73
>>
>>Since I don't have anything in the /etc/vserver/jco1.sh script, there's
>>nothing started. The only thing that is set, is the ip address.
>
>
> We got the same problem ;-)
Nope, the thing you are describing below is not a problem. :)
.
> If you try 'vserver v1 stop' v1 stops and the virtual net if is deleted as
> well. But if you try to start it again with 'vserver v1 start' you got
> the output as in 'jco1' but no server is startet, the virtuel net if is
> startet.
If you read the manual, you'll see that there's nothing special started besides the
daemons you bring up at boot time. So starting a vserver with vserver <name> start starts
all the things in /etc/vserver/<name>.sh and in the etc/rc.d/rcX.d of your server. If you
don't have anything in there, the vserver is virtually not running.
If I add the following to the post-start section of the jco1.sh script:
vserver jco1 exec /usr/local/apache/bin/apachectl start
then the httpd is started when starting the jail. This also means that there's one program
running in the vserver, so vserver jco1 status returns "jco1 running".
Here something from the documentation:
Oddly, starting a virtual server does not mean much. There is no overhead. No monitoring
process or proxy or emulator. Starting a virtual server with 4 services is the same as
running those 4 services in the main server, at least performance wise (the service inside
a virtual server are locked inside the security context).
--> so if you don't start any services, there "is" no virtual server.
> My idea is that all the .sh is made for RH and therefore not working for
> SuSE. Well, i think it's ours problem :)
>
> I am seeking a solution, and if it is nessesary i will make new scripts
> thats not distribution dependent.
The SuSE /etc/rc.d/rc script seems definately to be a problem for vserver, since it seems
to combine the rc.sysinit, rc and rc.local script in a single script.