Difference between revisions of "util-vserver:InitStyles"

From Linux-VServer

Jump to: navigation, search
(Configuration)
 
(8 intermediate revisions by 4 users not shown)
Line 2: Line 2:
  
 
* plain
 
* plain
** Launches a unique init process for the guest.
+
** Launches a unique init process for the guest that appears to run as PID 1.
 
** Guest's init process executes the rc scripts.
 
** Guest's init process executes the rc scripts.
 
** Therefore, you cannot watch the startup process.
 
** Therefore, you cannot watch the startup process.
** However, shutdown or restart command will work
+
** However, any shutdown or restart command should work
 
* sysv (default)
 
* sysv (default)
 
** Executes the runlevel scripts directly.
 
** Executes the runlevel scripts directly.
** You can you can watch the startup process.
+
** You can watch the startup process.
 
** Slightly lighter weight since no additional init process is needed.
 
** Slightly lighter weight since no additional init process is needed.
** A fake init process is shown in the guest.
+
** The vserver sees a fake init with PID 1 that has the same properties as the real init on the host.
** You must use "reboot -f" or "halt -f" to restart or shut down from withint the guest.
+
** You must use "reboot -f" or "halt -f" to restart or shut down from within the guest.
 +
** Default start runlevel is 3, and stop is 6
 
* gentoo
 
* gentoo
 
** Like sysv but works on Gentoo-based guests.
 
** Like sysv but works on Gentoo-based guests.
Line 26: Line 27:
 
   /etc/vservers/<NAME>/apps/init/style
 
   /etc/vservers/<NAME>/apps/init/style
  
If the file doesn't exist or the word isn't recognized, sysv will be used.
+
If the file doesn't exist, sysv will be used.  If the word isn't recognized, the guest will not be started and an error will be printed.
 +
 
 +
=== Using runit ===
 +
 
 +
[http://smarden.org/runit/ runit] is an init replacement that provides service monitoring. There currently are at least three ways to use it with vserver:
 +
 
 +
* Set initstyle to plain; this allows you to launch your own <tt>runit</tt> inside the vserver.
 +
** This is the most straightforward way. Guests can shut themselves down and restart as usual. Disadvantage: once extra runit-init process per guest.
 +
* Use a persistent context for the guest, and just run the services inside it, not runit itself. This is discussed in [[Running runit-supervised services inside a vserver]].
 +
* Set initstyle to <tt>sysv</tt>, but <tt>cmd.start</tt> to "<tt>/etc/runit/2</tt>" and <tt>cmd.stop</tt> to "<tt>/etc/runit/3</tt>".
 +
** Advantage: you can run a vserver supervised by <tt>runit</tt> running on the host.
 +
 
 +
For this to work, you must customize <tt>/etc/runit/2</tt> in the vserver as follows:
 +
 
 +
<pre>
 +
#!/bin/sh
 +
 
 +
trap ":" HUP INT QUIT ILL TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS
 +
 
 +
PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
 +
 
 +
runsvchdir default >/dev/null
 +
 
 +
env - PATH=$PATH \
 +
runsvdir -P /var/service 'log: ...........................................................................................................................................................................................................................................................................................................................................................................................................'
 +
 
 +
exec /etc/runit/3
 +
</pre>
 +
 
 +
Now, you can set up a <tt>runit</tt> service on the host with a <tt>run</tt> script like this one:
 +
 
 +
<pre>
 +
#!/bin/sh
 +
exec 2>&1
 +
exec vserver name-of-vserver start
 +
</pre>
 +
 
 +
This way:
 +
 
 +
* <tt>vserver start</tt> doesn't exit until <tt>runsvdir</tt> terminates.
 +
* If <tt>runsvdir</tt> terminates, all services running inside the vserver are stopped.
 +
* <tt>vserver stop</tt> works as expected.
 +
** Update: with util-vserver 0.30.212 on amd64, it doesn't. The signal never reaches <tt>runsvdir</tt>.
 +
* You can control the vserver using <tt>sv</tt> like any other service, provided all processes running inside it are managed by <tt>runit</tt>.
 +
** If there are processes left inside after all the services exited, <tt>runit</tt> running on the host won't be able to restart the vserver until those stray processes are killed somehow.
 +
** You may want to add something to this effect to the <tt>finish</tt> script of the vserver service, but it may not be a good idea. Be sure you know what you are doing, as always.
 +
 
 +
Still, this may not be the best way to integrate <tt>runit</tt> with vserver. [[Running runit-supervised services inside a vserver]] may be better if you only run a specific service in a guest and it seems wasteful to keep extra processes around. Using the plain initstyle and starting runit-init in each guest is best if you want to make your guests behave like a physical system. It's also the most hassle-free approach.
 +
 
 +
--[[User:KornAndras|Guy-]] 02:30, 2 February 2007 (CET)
 +
 
 +
[[Category:Configuration]]

Latest revision as of 22:17, 21 October 2011

Guests can be started using one of the following init styles:

  • plain
    • Launches a unique init process for the guest that appears to run as PID 1.
    • Guest's init process executes the rc scripts.
    • Therefore, you cannot watch the startup process.
    • However, any shutdown or restart command should work
  • sysv (default)
    • Executes the runlevel scripts directly.
    • You can watch the startup process.
    • Slightly lighter weight since no additional init process is needed.
    • The vserver sees a fake init with PID 1 that has the same properties as the real init on the host.
    • You must use "reboot -f" or "halt -f" to restart or shut down from within the guest.
    • Default start runlevel is 3, and stop is 6
  • gentoo
    • Like sysv but works on Gentoo-based guests.
    • Was deprecated but has been reinstated around util-vserver 0.30.212.
  • minit

[edit] Configuration

The init style should go in a file containing a single word: sysv, plain, etc.

 /etc/vservers/<NAME>/apps/init/style

If the file doesn't exist, sysv will be used. If the word isn't recognized, the guest will not be started and an error will be printed.

[edit] Using runit

runit is an init replacement that provides service monitoring. There currently are at least three ways to use it with vserver:

  • Set initstyle to plain; this allows you to launch your own runit inside the vserver.
    • This is the most straightforward way. Guests can shut themselves down and restart as usual. Disadvantage: once extra runit-init process per guest.
  • Use a persistent context for the guest, and just run the services inside it, not runit itself. This is discussed in Running runit-supervised services inside a vserver.
  • Set initstyle to sysv, but cmd.start to "/etc/runit/2" and cmd.stop to "/etc/runit/3".
    • Advantage: you can run a vserver supervised by runit running on the host.

For this to work, you must customize /etc/runit/2 in the vserver as follows:

#!/bin/sh

trap ":" HUP INT QUIT ILL TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS

PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin

runsvchdir default >/dev/null

env - PATH=$PATH \
runsvdir -P /var/service 'log: ...........................................................................................................................................................................................................................................................................................................................................................................................................'

exec /etc/runit/3

Now, you can set up a runit service on the host with a run script like this one:

#!/bin/sh
exec 2>&1
exec vserver name-of-vserver start

This way:

  • vserver start doesn't exit until runsvdir terminates.
  • If runsvdir terminates, all services running inside the vserver are stopped.
  • vserver stop works as expected.
    • Update: with util-vserver 0.30.212 on amd64, it doesn't. The signal never reaches runsvdir.
  • You can control the vserver using sv like any other service, provided all processes running inside it are managed by runit.
    • If there are processes left inside after all the services exited, runit running on the host won't be able to restart the vserver until those stray processes are killed somehow.
    • You may want to add something to this effect to the finish script of the vserver service, but it may not be a good idea. Be sure you know what you are doing, as always.

Still, this may not be the best way to integrate runit with vserver. Running runit-supervised services inside a vserver may be better if you only run a specific service in a guest and it seems wasteful to keep extra processes around. Using the plain initstyle and starting runit-init in each guest is best if you want to make your guests behave like a physical system. It's also the most hassle-free approach.

--Guy- 02:30, 2 February 2007 (CET)

Personal tools