SNTOP(1) | General Commands Manual | SNTOP(1) |
sntop
— top-like
console network status tool
sntop |
[options] |
sntop
(simple network top) is a console
utility, in the spirit of top, that polls a list of hosts at a regular
interval to determine if they are online, displaying the results in a
formatted table. This list is read on load from a config file, sntoprc,
located (by default) in ~/ or /etc. The polling is done via ICMP
ping (1)
Optionally, the results can be used to generate an html page or elicit the execution of a file.
Interactive run-time commands exist:
q
- quit
r
- reload config file
w
- toggle html page generation
any other key
- force a refresh
-d, --daemon
- daemon mode: make sntop
capable of running in the background. note, it wont automatically fork into
the background.
-o, --once
- poll and display results
once, then exit
-c, --nocolor
- toggle the use of ncurses
color for pretty formatting
-p, --ping
- use 'ping' in lieu of
'fping'. note, ping (in particular on DOWN hosts) is slower than fping --
the performance of sntop will suffer.
-w, --html
- generate html output of
results
-s, --secure
- secure mode. command keys
are disabled. SIGINT must be used to terminate the program. this allows
sntop to run nicely on spare terminals galore. something like the following
in /etc/passwd can facilitate that:
sntop:x:123:123:sntop:/:/usr/local/bin/sntop
-s
-e <file>, --wfile=file
- output
html to <file> instead of sntop.html
-f <file>, --conf=file
- read conf
data from <file> instead of ~/.sntoprc. note, sntop will still try to
read from /etc/sntoprc if <file> fails. if both fail, sntop will
exit.
-r <time>, --refresh=time
- refresh
every <time> seconds instead of 180
-a <file>, --alarm=file
- alarm
mode: execute <file> when a site first goes DOWN
-l <file>, --log=file
- log mode:
execute <file> whenever the status of a site changes
-b <bytes>, --byte=bytes
- Number of
bytes of ping data to send
-v, --version
- display version
information and exit
-h, --help
- display command-syntax help
and exit
In alarm or log mode a file is executed on the occurrence of change in status of a given host. sntop will fork and exec the specified file, passing as arguments information about the event. those arguments are:
<display name of host> <host name/IP> <status>
<display name of host> the 'display' name (first sntop column) of the machine, ie "MyBox"
<host name/IP> the explicit hostname or IP address of the machine, ie "snaggle" or "192.168.55.12"
<status> the new status of the machine, "UP" or "DOWN," this would obviously always be DOWN for alarm mode
Note, DOWN hosts will be logged in both modes upon load (ie, if they are down when sntop loads, <file> is executed). No action is taken in any modes for hosts that originate as UP -- thus, the default status is UP. We execute an external file to remain in the UNIX tradition -- small, simple programs that do one thing damn well. Thus, a logging option is not even provided -- a two-line shell script will do fine, there. However, the possibilities are powerful: administrator paging, for instance. See alarm.sh for an example script.
~/.sntoprc default config file location
/etc/sntoprc if a user's config is not found, this system-wide one is read
/usr/share/man/man1/sntop.1.gz the man page
/usr/share/doc/sntop/examples/alarm.sh sample alarm-execute script
/usr/bin/sntop the sntop executable
An example config file, /usr/share/doc/sntop/examplessntoprc.EXAMPLE, is included in the standard distribution. However, the config file syntax is simple. Entries are RETURN terminated. Trailing whitespace is ignored. '#' signifies a comment and can be used inline. By default, upto 32 characters will be read, per line. All entries should be a single word, except comments. The syntax:
Display Name
IP or host
Display Comments
Example:
Jimi
192.168.23.1
linux/sparc; firewall, http, ftp
sntop
will first attempt to read the
config file from ~/.sntoprc (or another location
specified by -f). If that fails, the system config file will be read from
/etc/sntoprc. If both fail, sntop will exit.
sntop
was written by Robert M. Love
<rml@tech9.net> and Christopher M. Rivera <cmrivera@ufl.edu>.
Send us bug reports, suggestions, and hardware.
top (1), ping (1), fping (1)
October 22, 2008 |