Difference between revisions of "util-vserver:InitStyles"

Revision as of 09:50, 22 April 2009

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
  • Like plain init but smaller.
  • minit must be installed on the guest.
  • http://www.fefe.de/minit/

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.

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)