HP-UX Containers (SRP) A.03.01 Administrator's Guide

7 Using the srp_init command

The /sbin/srp_init command serves as a daemon and as a command to interact with the

daemon. The srp_init daemon is the first process launched inside a container when the container

is started. The srp_init daemon is a container process spawner that launches processes based on

the entries in the container’s /etc/inittab file. It also monitors the processes it spawns during the

lifetime of the container.

7.1 Changing the run level of a container

You can use the srp_init command to communicate with the srp_init daemon to change the run

level of a container. The srp_init command must be executed from within a container to target the

correct srp_init daemon. Similar to the init(1M) command, it accepts a one-character

argument and signals the srp_init daemon with the kill(2) system call to perform the

appropriate action. The default run level is set to 3 and is defined in the /etc/inittab file

(/var/hpsrp/container_name/etc/inittab for a workload container).

The srp_init command has the following syntax:

/sbin/srp_init 0|1|2|3|4|5|6|Q|q

Where 0|1|2|3|4|5|6|Q|q identifies the specified run level.

NOTE: The container run level is independent of the system run level described in rc(1M).

Containers cannot be started on the system until the system level init daemon has reached run level

The srp_init has the following restrictions:

• S|s,a,b,c run level options supported by system init (see init(1M)) are not recognized

by the srp_init command.

• Boot authentication as described in security(4) is not supported

• The getty entries in the container’s inittab file are ignored

• As HP-UX Containers does not support per container console, console interaction including

internally restarting the container after srp_init 0 is not supported. After executing

srp_init 0 from within the container, you must stop and restart the container from the

global view via the srp command.

• The process ID of srp_init will not be 1. The process ID of srp_init is non-deterministic.

The SIGPWR signal is masked (ignored) by srp_init. All other signals remain unmasked by

srp_init, hence srp_init can be killed by an appropriately privileged process.

If the srp_init daemon is not running in a container, you can restart it in one of the two ways:

1. /sbin/srp_init - Restarts srp_init at the last recorded run level in the per container

utmp database.

2. /sbin/srp_init <run level> - Restarts srp_init to a specified run level. In this

case, srp_init starts with the last recorded run level in the per-container utmp database,

and then transition to the new run level specified.