RTMOND(1)RTMOND(1)NAMErtmond - system event monitoring daemon
SYNOPSIS
/usr/etc/rtmond [ options ]
DESCRIPTIONrtmond is the server process that collects system and user events and
dispatches them to clients such as padc(1), IRIXview(1), and rtmon-
client(1). In normal operation, rtmond is atomatically started when the
system is booted. Only one copy of rtmond can be started per machine.
When clients connect to rtmond and request event data, rtmond creates
additional children to collect event data from each CPU that event data
is being requested for (if such children are not already running) and one
more child to manage the transfer of the event data to the client.
OPTIONS-a access-spec
Use access-spec to control all client accesses; overriding
anything given in the normal client access control file. See
below for a description of the client access control mechanism.
-b iobufsiz
Use iobufsiz when allocating buffers that hold event data that
is to be written to a client. By default rtmond allocates up
to five 16 kilobyte buffers for each client, for each CPU on
which event data is collected. See also the -i option below.
-c Enable the generation of checksums in event records transmitted
to clients. Checksums are used for debugging data corruption
problems and should not be generally enabled as it slows down
the server; potentially causing events to be lost.
-d Do not detach from the controlling terminal and direct all
diagnostic messages to the standard error descriptor. By
default rtmond detaches itself from the controlling terminal
and directs all diagnostic messages to the syslogd(1M) service.
This option is useful when debugging the server.
-f access-file
Take client access control information from access-file. By
default rtmond looks for client access control information in
the file /etc/rtmond.
-H When reporting the name of kernel threads to clients, attempt
to send a more meaningful name. For interrupt handling threads
it will attempt to send the name of the actual handler function
instead of a generic interface name as is more often the case.
In order for this option to work correctly, the eoe.sw.kdebug
package must be installed.
Page 1
RTMOND(1)RTMOND(1)-i maxiobufs
Use maxiobufs as the upper bound on the number of buffers
allocated for holding event data that is to be written to a
client. By default rtmond allocates up to five buffers for
each client, for each CPU on which event data is collected.
See also the -b option above.
-l Force the server process and event collection threads to lock
themselves in memory. When this is specified rtmond uses the
plock(2) system call to lock its text and data segments into
memory. This option may be useful if rtmond is losing events
because it is paged or swapped out of memory. Beware however
that on large multiprocessor systems this may cause lots of
locked-down memory to be requested, which may not be possible.
-p priority
Use priority to set the scheduling priority for the server and
each event collection thread spawned by the server. By default
rtmond uses a realtime scheduling priority of 88; this option
can be used to specify an alternate non-degrading priority.
-P port Use port for the TCP port number on which client connections
are received. By default rtmond uses the port number
associated with the ``rtmon'' service; otherwise falling back
to port 1455.
-q quiettime
Use quiettime for the time interval for issuing ``null
records'' to clients (specified in milliseconds). A null
record is sent to a client when there has been no data for a
CPU for an extended period of time. This mechansim assists
clients in merging event data streams from multiple CPUs. By
default rtmond uses a 200 millisecond quiet time interval.
-t trace-mask
Enable diagnostic tracing messages in the areas specified by
trace-mask. Tracing messages are broken up into areas that are
identified symbolically by the following:
Name Description
access Client access control operations
all All tracing facilities
client Client data connection setup and teardown
debug Miscellaneous information for debugging
eventio Client event data write operations
events Event collection low-level operations
lostevents Kernel lost event actions
none No events (for disabling tracing)
perf Client performance statistics
kid Process/thread ID cache management
rpc Client-server protocol
sync Time synchronization work
Page 2
RTMOND(1)RTMOND(1)
thread Event collection thread operations
tstamp Kernel tstamp operations
Area names are case insensitive. To trace multiple areas
combine the names with ``,'', ``|'', or ``+''. To exclude
areas use a ``-'' as a separator; e.g. ``all-tstamp-eventio''.
Beware that tracing some areas of operation can result in
events being lost; the ``events'' area is an example.
By default rtmond does not emit any trace messages. ``perf''
messages are always emitted if client events are lost in order
to provide a log to check against problem reports.
-U pathname
Use pathname for the name of the UNIX domain socket on which
client connections are received. By default rtmond listens for
connections on a socket bound to the pathname
/tmp/.rtmond_socket.
-w waittime
Use waittime for the time threshold for waiting for the system
event queue to reach the low water mark (specified in
milliseconds). While rtmond is waiting for the system event
queue to fill up it blocks and is incapable of processing
events from applications. Consequently this time value
controls the maximum delay for a user-level event to be
dispatched to interested clients. By default rtmond uses a
waittime of 100 milliseconds.
-z Enable system call tracing for all the event collection threads
rtmond spawns. By default rtmond disallows system call tracing
on the event collection threads to avoid loading the system.
if this option is specified then global system call tracing
will include system calls done by these threads. It is
recommended that this option be used only for debugging rtmond.
EVENT MASKS
An event mask specifies a set of events; either the set of events that a
client may request be collected, or possibly the set of events to be
collected on behalf of a client. An event mask is specified as a set of
event classes with each class specified symbolically as one of the
following:
Name Description
all All events
alloc Memory allocation
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)
Page 3
RTMOND(1)RTMOND(1)
none No events
profile Kernel profiling
scheduler Process and thread scheduler
signal Signal delivery and reception
syscall System calls and their arguments
task Process and thread scheduling
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>''.
CLIENT ACCESS CONTROL
Clients communicate with rtmond using a special-purpose client-server
protocol. Requests are used to query the state of a system (e.g. the
number of processors) and to control data collection. rtmond screens
service requests using a client access control mechanism.
Client access control specifies which hosts may receive service and which
events they may request collection of. This is done using either an
ASCII file or a global specification that is given on the command line
when rtmond is started up. Each control specification is of the form:
regex[:event-mask]
where regex is a regular expression that is matched against client host
names and dot addresses, and event-mask is an optional specification of
the set of events that may be received (see above). For example,
``.*[.]sgi[.]com:all-syscall'' disallows any host in the ``.sgi.com''
domain from enabling system call tracing. Access control files are
simply collections of access control specifications; one per line with
comments indicated by a ``#'' character (everything to the end of that
line is discarded). rtmond applies the regular expressions given in a
file in the order in which they appear; the first expression that matches
the name or address of a client is used to restrict the events that can
be retrieved. Note that if a client requests events that it is not
permitted to receive the entire request is rejected. Any denial of
service due to an access control restriction is logged through the normal
mechanisms (typically syslog). The ``access' trace mask can also be used
to trace other access control operations.
Regular expressions involving hex format IPv6 addresses are not supported
at this time.
FILES
/tmp/.rtmond_pid server PID stash
Page 4
RTMOND(1)RTMOND(1)
/tmp/.rtmond_socket UNIX domain socket for client connections
/usr/tmp/.rtmond_shm_file shared memory file for user events
/etc/rtmond default client access control info
/etc/config/rtmond.options standard system startup options and arguments
for rtmondSEE ALSOpadc(1), rtmon-client(1), rtmon_log_user_tstamp(3)
Page 5
