RTMON-CLIENT(1)RTMON-CLIENT(1)NAMErtmon-client - client for collecting real-time event data from rtmond
SYNOPSISrtmon-client [ -d ] [ -f filename ] [ -h hostname ] [ -p cpu-list ] [ -m
event-mask ] [ -n ] [ -O ] [ -t timeout ] [ -v ]
DESCRIPTIONrtmon-client connects to the rtmond daemon running on the machine
hostname and collects event data for one or more CPUs. This event data
can be displayed by programs such as par(1), rtmon-dump(1), and the
optional IRIXview(1) product.
If event collection is done for an unspecified period of time (see the -t
option below) then rtmon-client will collect event data until it is
interrupted.
OPTIONS-d Enable debugging. Debugging enables additional error messages and
the creation of a debugging file that contains a human readable list
of the events that were collected (see the -f option below).
-f filename
Write event data to one or more files with names derived from
filename. In normal operation rtmon-client will write all event
data to a single file named filename. If the -O option is specified
then event data is written to multiple files, one for each CPU where
data is collected, and these files are named filename.wvr.cpu, where
cpu is the number of the CPU on which data was collected. In
addition, if debugging is enabled with the -d option, per-CPU
debugging information is written to files named filename.dbg.cpu.
By default rtmon-client uses the string default in constructing file
names.
-h hostname
Connect to the server on the specified host. rtmon-client first
tries to use hostname as the pathname of a UNIX domain socket on the
local host; that failing it tries it as a host name or Internet
address (specified using the usual ``dot notation''). If hostname
is an empty string then rtmon-client uses the default scheme for
connecting to a server: first try to reach a server through the
default UNIX domain socket, if that fails contact a server through
the loopback interface.
-p cpu-list
Collect data on the set of CPUs specified by cpu-list. CPUs are
specified as a comma-separated list of CPU numbers or range of CPU
numbers. CPUs are numbered starting at zero. For example, -p 1,4-
7,11 means processors 1, 4, 5, 6, 7, and 11. An open-ended range is
interpreted as all CPUs to the maximum CPU number; e.g. 2- on an
8-processor system is the same as 2-7. The CPU list must be one
string with no white space. By default, rtmon-client collects data
Page 1
RTMON-CLIENT(1)RTMON-CLIENT(1)
for all CPUs.
-m event-mask
Collect only events specified by event-mask. An event mask
specifies a set of events; it is a set of event classes with each
class specified symbolically as one of the following:
Name Description
all All events (default)
alloc Memory allocation
cxfs CXFS vnode and meta data events
disk Disk i/o work
intr Hardware interrupts
io I/O-related events (disk+intr)
netflow Network I/O flow
netsched Network I/O scheduling
network Network-related events (netflow+netsched)
profile Kernel profiling
scheduler Process and thread scheduler
signal Signal delivery and reception
syscall System calls and their arguments
task Process and thread scheduling
taskproc Process scheduling (system threads are not included)
vm Virtual memory operation
Event class names are case insensitive; i.e. ``SIGNAL'' is
interpreted the same as ``signal''. Multiple event classes may be
included by using a ``+'', ``|'', or ``,'' symbol to separate the
names. Event classes may be excluded by using a ``-'' to separate
the name. For example, ``network+io-disk'' indicates all network
and i/o events should be included except for disk-related events.
In addition to the above names, a number may be used to specify a
value, where the various events are selected by bits in the value,
as defined in ``<sys/rtmon.h>''.
Note that under some circumstances events not in the specified
classes may also be collected. This can happen when ``unclassified
events'', such as those generated by user applications, are
collected.
-n Do not merge the per-CPU event data streams. This can be useful if
merging slows down rtmon-client so much that it causes data to
dropped by the server.
-t timeout
Collect data for timeout seconds.
-v When rtmon-client is used to collect data from a remote system (via
the -h option) it is not normally possible to collect system call
event data for processes unless the remote processes are specially
marked to allow the data to be collected. This marking must be
performed on the remote system via rtmon-run(1). Permissions to
Page 2
RTMON-CLIENT(1)RTMON-CLIENT(1)
perform this marking are handled via standard process permissions on
the remote system. Access to the system call data is controlled via
a security cookie that is granted by the remote rtmond. When the -v
option is provided to rtmon-client this security cookie is printed.
The security cookie must then be used in the rtmon-run command on
the remote system in order to properly tag the collected system call
data.
DIAGNOSTICS
Unable to contact rtmon service on host <hostname>. There is no rtmond
server process running on the target system.
SEE ALSOpar(1), rtmon-run(1), rtmond(1), IRIXview(1), rtmon_log_user_tstamp(3)
Page 3
