Viewing Solaris zone resource utilization

Solaris zones have been around for quite some time now, and provide low overhead execution environments for running application. Admins who need to understand how zones are utilizing CPU and memory resources typically turn to prstat, which provides the “-Z” option to view utilization by zone:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
448 foo 165M 141M sleep 59 0 21:47:34 37% java/115
7713 matty 2292K 1740K cpu0 59 0 0:00:00 0.0% prstat/1
233 snmp 7348K 5336K sleep 59 0 0:00:46 0.0% snmpd/1
316 daemon 2100K 1344K sleep 60 -20 0:00:00 0.0% lockd/2
309 root 1752K 944K sleep 59 0 0:00:00 0.0% sac/1
492 root 8688K 7740K sleep 29 0 0:00:01 0.0% svc.startd/11
459 root 0K 0K sleep 60 – 0:00:00 0.0% zsched/1
129 root 2192K 1328K sleep 29 0 0:00:00 0.0% syseventd/14
123 root 2964K 2024K sleep 29 0 0:00:00 0.0% picld/5
202 root 2432K 976K sleep 59 0 0:00:00 0.0% cron/1
402 root 3520K 1328K sleep 59 0 0:00:00 0.0% sshd/1
136 root 6552K 3772K sleep 29 0 0:00:00 0.0% devfsadm/9
303 daemon 2432K 972K sleep 59 0 0:00:00 0.0% rpcbind/1
140 root 4376K 3120K sleep 59 0 0:00:02 0.0% nscd/24
137 daemon 3892K 2036K sleep 29 0 0:00:00 0.0% kcfd/3
236 nobody 3324K 1044K sleep 59 0 0:00:03 0.0% nrpe/1
827 root 9176K 8144K sleep 59 0 0:00:03 0.0% svc.configd/14
823 root 2160K 1248K sleep 59 0 0:00:00 0.0% init/1
421 smmsp 7072K 1492K sleep 59 0 0:00:00 0.0% sendmail/1
9 root 9516K 8504K sleep 29 0 0:00:03 0.0% svc.configd/15
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
0 35 213M 215M 1.3% 21:49:10 37% global
3 21 43M 50M 0.3% 0:00:15 0.0% zone1
1 21 43M 50M 0.3% 0:00:15 0.0% zone2
2 21 42M 50M 0.3% 0:00:16 0.0% zone3

While reviewing the Solaris zones mailing list last night, I noticed that Jeff Victor posted a link to a Perl script that can provide utilization data for zones. This script has a TON of potential, especially once it is able to report on network and disk utilization.

Deciphering shell exit codes

I was recently debugging an issue with a shell script, and noticed that the shell was exiting with an exit code greater than 100 when it received a SIGTSTP signal:

$ cat test

#!/bin/bash
sleep 60

# Window one
$ ./test
[1]+ Stopped ./test
Home:~ matty$ echo $?
146

# Window two
$ kill -18 4667

I was curious where the exit value of 146 came from, so I did a bit of digging. It turns out that when a shell exits due to an uncaught signal, the signal number is added to 128 and that is the value that is returned. So in the case above, the exit code 146 was returned. I digs me some random shell knowledge.