Util-vserver:InitStyles: Difference between revisions
No edit summary |
imported>Glenn |
||
| (7 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. | ||
| Line 8: | Line 8: | ||
* sysv (default) | * sysv (default) | ||
** Executes the runlevel scripts directly. | ** Executes the runlevel scripts directly. | ||
** You | ** 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. | ||
** | ** 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. | ** 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 | 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 21: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
- Like plain init but smaller.
- minit must be installed on the guest.
- http://www.fefe.de/minit/
Configuration[edit]
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[edit]
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)