Container Action Scripts

There might be situations when you need to do additional actions when a particular Container is started or stopped. For example, if you want to be able to access the server file system (or part of it) from Container 101, then you can bind mount it inside the Container manually from the server. However, after you restart the Container, your mount disappears, and you should manually type the mount command again. Parallels Cloud Server allows you to automate procedures like the above by using action scripts below.

Scripts

Name	Description
global mount	This script runs immediately after `prlctl` mounts the Container private area. The Container itself is not yet running and the script is running in the server context.
mount	This script runs immediately after the global mount script. The Container is still not running, and the script is called in the server context.
start	After `prlctl` has started a Container, it runs the Container `start` script. The script is running already in the Container context.
stop	This script runs before the Container is stopped, in the Container context.
umount	After the Container has been already stopped, the `umount` script is executed, and the script runs in the server context.
global umount	This script runs when `prlctl` is about to dismount the Container private area. It also runs in the servercontext.

It is important to understand how prlctl handles exit codes of action scripts. If exit code is non-zero, then prlctl will try to undo the action for the mount and start scripts. In other words, if the start script returns an error, then prlctl will stop Container, and if one of the mount scripts fails, then prlctl will dismount the Container private area. Please note that in this case prlctl will not execute the stop and umount scripts at all.

Caution: When executing prlctl start , both mount and start scripts run. However, if the start script fails then neither stop nor umount scripts will run. As a result, prlctl might be unable to dismount the Container private area, if you set up additional mounts in the mount scripts and dismount them in the umount scripts.

The situation with the umount and stop scripts is similar. If a script returns an error, then the action will not be taken. Be careful since this allows to create Containers that are not stoppable by prlctl .

The global scripts are named vps.mount and vps.umount and located in the /etc/vz/conf directory on the server. These scripts are called when any Container on the server is started or stopped. So, you should include in these scripts those commands that are common for all Containers and leave Container-specific commands for the scripts belonging to a particular Container. Container-specific action scripts are located in the /vz/private/ CT_ID /scripts directory and have the mount , start , stop , and umount names. For example, the scripts specific for Container 101 will have the following names:

/vz/private/101/scripts/mount
/vz/private/101/scripts/start
/vz/private/101/scripts/stop
/vz/private/101/scripts/umount

For the mount and umount scripts, the environment passed is the standard environment of the parent (i.e. prlctl ) with two additional variables: $VEID and $VE_CONFFILE . The first one holds the ID of the Container being mounted (started, stopped, dismounted), and the second one holds the full path to the Container configuration file. You can use the following fragment of the code in bash scripts to get access to additional Container information like $VE_PRIVATE or $VE_ROOT locations:

#!/bin/bash
#
# This script sources Container configuration files in the same
# order as prlctl does

# if one of these files does not exist then something is
# really broken
[ -f /etc/sysconfig/vz ] || exit 1
[ -f $VE_CONFFILE ] || exit 1

# source both files. Note the order, it is important
. /etc/vz/vz.conf
. $VE_CONFFILE

The start and stop scripts are performed in the Container context. If these scripts call any external commands, these commands are taken from the Container itself. Also note that the start script runs before any Container tasks (including init ), thus the /proc file system is not mounted inside the Container at this moment – therefore, applications using information from /proc may be not functional.

Top of page

Feedback