NAME
zone_monitor.sh - boot OmniCube zones that are installed but not running
SYNOPSIS
/opt/omnicube/sbin/zone_monitor.sh
zone_monitor.sh
DESCRIPTION
zone_monitor.sh restarts zones that should be up but are not. It takes no options and no operands and is meant for unattended periodic execution from root's crontab, alongside the other periodic jobs whose sample entries are shipped in /opt/omnicube/share/README. It is also useful by hand after a node has come back from maintenance, to boot everything that is supposed to autoboot in one step.
The script does not set its own PATH, so the invoking environment must resolve svcs, svcprop, zoneadm, zonecfg, ps and pfexec. It sources /opt/omnicube/lib/common/utils.sh for logging and the run-level guard.
Global service gate
Before looking at any zone the script runs svcs -xv. If that produces any output at all, the global zone still has services in maintenance or offline, so the script logs System not cleaned yet: <svcs output> through info() and exits 0 without touching a single zone. Booting zones on a host whose own service graph has not settled would only compound the problem.
Run-level guard
abort_if_shutting_down is called before the service gate and again at the top of every zone iteration, so the script exits 0 silently when the host is at run level 0, 1, 5, 6, S or s, or when /etc/nologin exists, and a shutdown starting part way through stops it before the next zone is booted. OC_IGNORE_RUNLEVEL set to a non-empty value overrides the guard.
Locking
This command takes no lock and does not enforce single-instance execution. The ten-second pause after each boot is the only pacing. Sourcing utils.sh still creates and normalises /var/run/omnicube as a side effect.
Per-zone decision
Each zone reported by zoneadm list -ni is examined in turn, and is booted only if all of the following hold.
A zone that passes all three is logged as Zone <zone> is stopped, starting it... and booted with pfexec zoneadm -z <zone> boot, after which the script sleeps ten seconds before considering the next zone.
Alerting
The script only ever calls info(), so every message goes to stdout and to syslog as user.info under the tag <site>zone_monitor, which /etc/rsyslog.d/omnicube.conf routes to /var/log/misc.log. It never calls warning() or error(), so it never sends oc-warn or oc-alert mail. A failing zoneadm boot is not diagnosed by the script: its own stderr is the only signal, which for a cron invocation means cron mail.
OPERANDS
This command takes no options and no operands. Any argument given is ignored.
SMF PROPERTIES
EXAMPLES
Example 1: five-minute cron entry
*/5 * * * * /opt/omnicube/sbin/zone_monitor.sh >/dev/null
Example 2: bring every autoboot zone up after maintenance
pfexec /opt/omnicube/sbin/zone_monitor.sh zoneadm list -ni
Example 3: keep one zone permanently down
svccfg -s svc:/service/omnicube/zone:zn06efit \\
setprop config/adm_status = astring: stopped
svcadm refresh svc:/service/omnicube/zone:zn06efit
EXIT STATUS
No other status is produced deliberately. In particular, the exit status does not report whether a zone actually booted; the script does not check the result of zoneadm boot.
FILES
ENVIRONMENT
SECURITY
Booting a zone requires pfexec, which needs the OmniCube Administration profile from /etc/security/prof_attr.d/omnicube and the /usr/sbin/zoneadm entry in /etc/security/exec_attr.d/omnicube. That profile is root-equivalent as a whole. Zone names come from zoneadm itself and are passed to ps through an awk variable rather than being interpolated into a regular expression.
SEE ALSO
manage_zone.sh(8), pool_monitor.sh(8), sys_monitor(8), zone_save.sh(8), zones_srv_monitor.sh(8), oc_log(3), oc_runlevel(3), omnicube_utils(3), omnicube(7).
NOTES
The global service gate makes this monitor all-or-nothing: one service in maintenance in the global zone stops every zone boot for as long as it lasts. Check svcs -xv first when zones are not coming up.
The script does not consult the isolation marker /var/run/omnicube/isolate_node.lock. On an isolated node the remote pools are offline, so a zone backed by them cannot boot and the attempt will be retried on every run. See isolate_node.sh(8).
Because there is no lock, two overlapping runs can both decide to boot the same zone. The ps check for an in-flight zoneadm narrows that window but does not close it.