rtmond(1)
rtmond - system event monitoring daemon
As shipped in IRIX 6.5. First release of IRIX 6.5.
NAME rtmond - system event monitoring daemon SYNOPSIS /usr/etc/rtmond [ options ] DESCRIPTION rtmond is the server process that collects system and user events and dispatches them to clients such as padc(1), WindView(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. -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 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 WindView 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) 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. FILES /tmp/.rtmond_pid server PID stash /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 SEE ALSO padc(1), rtmon-client(1), rtmon_log_user_tstamp(3)