xymond

title: xymond(8)

text:
# xymond(8)

## NAME
xymond - Master network daemon for a Xymon server

## SYNOPSIS
xymond [options]

## DESCRIPTION
xymond is the core daemon in the Xymon Monitor. It is designed to handle monitoring of a large number of hosts, with a strong focus on being a high-speed, low-overhead implementation of a Big Brother compatible server.

To achieve this, xymond stores all information about the state of the monitored systems in memory, instead of storing it in the host filesystem. A number of plug-ins can be enabled to enhance the basic operation; e.g. a set of plugins are provided to implement persistent storage in a way that is compatible with the Big Brother daemon. However, even with these plugins enabled, xymond still performs much faster than the standard bbd daemon.

xymond is normally started and controlled by the xymonlaunch(8) tool, and the command used to invoke xymond should therefore be in the tasks.cfg file.

## OPTIONS
--hosts=FILENAME

Specifies the path to the Xymon hosts.cfg file. This is used to check if incoming status messages refer to known hosts; depending on the "--ghosts" option, messages for unknown hosts may be dropped. If this option is omitted, the default path used is set by the HOSTSCFG environment variable.

--checkpoint-file=FILENAME

With regular intervals, xymond will dump all of its internal state to this check-point file. It is also dumped when xymond terminates, or when it receives a SIGUSR1 signal.

--checkpoint-interval=N

Specifies the interval (in seconds) between dumps to the check-point file. The default is 900 seconds (15 minutes).

--restart=FILENAME

Specifies an existing file containing a previously generated xymond checkpoint. When starting up, xymond will restore its internal state from the information in this file. You can use the same filename for "--checkpoint-file" and "--restart".

--ghosts={allow|drop|log|match}

How to handle status messages from unknown hosts. The "allow" setting accepts all status messages, regardless of whether the host is known in the hosts.cfg file or not. "drop" silently ignores reports from unknown hosts. "log" works like drop, but logs the event in the xymond output file. "match" will try to match the name of the unknown host reporting with the known names by ignoring any domain-names - if a match is found, then a temporary client alias is automatically generated. The default is "log".

--no-purple

Prevent status messages from going purple when they are no longer valid. Unlike the standard bbd daemon, purple-handling is done by xymond.

--merge-clientlocal

The client-local.cfg(5) file contains client-configuration which can be found matching a client against its hostname, its classname, or the name of the OS the client is running. By default xymond will return one entry from the file to the client, looking for a hostname, classname or OS match (in that order). This option causes xymond to merge all matching entries together into one and return all of it to the client.

--listen=IP[:PORT]

Specifies the IP-address and port where xymond will listen for incoming connections. By default, xymond listens on IP 0.0.0.0 (i.e. all IP- addresses available on the host) and port 1984.

--lqueue=NUMBER

Specifies the listen-queue for incoming connections. You don't need to tune this unless you have a very busy xymond daemon.

--no-bfq

Tells xymond to NOT use the local messagequeue interface for receiving status- updates from xymond_client and xymonnet.

--daemon

xymond is normally started by xymonlaunch(8). If you do not want to use xymonlaunch, you can start xymond with this option; it will then detach from the terminal and continue running as a background task.

--timeout=N

Set the timeout used for incoming connections. If a status has not been received more than N seconds after the connection was accepted, then the connection is dropped and any status message is discarded. Default: 10 seconds.

--flap-count=N

Track the N latest status-changes for flap-detection. See the --flap-seconds option also. To disable flap-checks globally, set N to zero. To disable for a specific host, you must use the "noflap" option in hosts.cfg(5). Default: 5

--flap-seconds=N

If a status changes more than flap-count times in N seconds or less, then it is considered to be flapping. In that case, the status is locked at the most severe level until the flapping stops. The history information is not updated after the flapping is detected. NOTE: If this is set higher than the default value, you should also use the --flap-count option to ensure that enough status-changes are stored for flap detection to work. The flap-count setting should be at least (N/300)-1, e.g. if you set flap-seconds to 3600 (1 hour), then flap-count should be at least (3600/300)-1, i.e. 11. Default: 1800 seconds (30 minutes).

--delay-red=N

--delay-yellow=N

Sets the delay before a red/yellow status causes a change in the web page display. Is usually controlled on a per-host basis via the delayred and delayyellow settings in hosts.cfg(5) but these options allow you to set a default value for the delays. The value N is in minutes. Default: 0 minutes (no delay). Note: Since most tests only execute once every 5 minutes, it will usually not make sense to set N to anything but a multiple of 5.

--env=FILENAME

Loads the content of FILENAME as environment settings before starting xymond. This is mostly used when running as a stand-alone daemon; if xymond is started by xymonlaunch, the environment settings are controlled by the xymonlaunch tasks.cfg file.

--pidfile=FILENAME

xymond writes the process-ID it is running with to this file. This is for use in automated startup scripts. The default file is $XYMONSERVERLOGS/xymond.pid.

--log=FILENAME

Redirect all output from xymond to FILENAME.

--store-clientlogs[=[!]COLUMN]

Determines which status columns can cause a client message to be broadcast to the CLICHG channel. By default, no client messages are pushed to the CLICHG channel. If this option is specified with no parameter list, all status columns that go into an alert state will trigger the client data to be sent to the CLICHG channel. If a parameter list is added to this option, only those status columns listed in the list will cause the client data to be sent to the CLICHG channel. Several column names can be listed, separated by commas. If all columns are given as "!COLUMNNAME", then all status columns except those listed will cause the client data to be sent.

--status-senders=IP[/MASK][,IP/MASK]

Controls which hosts may send "status", "combo", "config" and "query" commands to xymond. By default, any host can send status-updates. If this option is used, then status-updates are accepted only if they are sent by one of the IP-addresses listed here, or if they are sent from the IP-address of the host that the updates pertains to (this is to allow Xymon clients to send in their own status updates, without having to list all clients here). So typically you will need to list your servers running network tests here.

The format of this option is a list of IP-addresses, optionally with a network mask in the form of the number of bits. E.g. if you want to accept status-updates from the host 172.16.10.2, you would use

--status-senders=172.16.10.2

whereas if you want to accept status updates from both 172.16.10.2 and from all of the hosts on the 10.0.2.* network (a 24-bit IP network), you would use

--status-senders=172.16.10.2,10.0.2.0/24

--maint-senders=IP[/MASK][,IP/MASK]

Controls which hosts may send maintenance commands to xymond. Maintenance commands are the "enable", "disable", "ack" and "notes" commands. Format of this option is as for the --status-senders option. It is strongly recommended that you use this to restrict access to these commands, so that monitoring of a host cannot be disabled by a rogue user - e.g. to hide a system compromise from the monitoring system. Note: If messages are sent through a proxy, the IP-address restrictions are of little use, since the messages will appear to originate from the proxy server address. It is therefore strongly recommended that you do NOT include the address of a server running xymonproxy in the list of allowed addresses.

--www-senders=IP[/MASK][,IP/MASK]

Controls which hosts may send commands to retrieve the state of xymond. These are the "xymondlog", "xymondboard" and "xymondxboard" commands, which are used by xymongen(1) and combostatus(1) to retrieve the state of the Xymon system so they can generate the Xymon webpages. Note: If messages are sent through a proxy, the IP-address restrictions are of little use, since the messages will appear to originate from the proxy server address. It is therefore strongly recommended that you do NOT include the address of a server running xymonproxy in the list of allowed addresses.

--admin-senders=IP[/MASK][,IP/MASK]

Controls which hosts may send administrative commands to xymond. These commands are the "drop" and "rename" commands. Access to these should be restricted, since they provide an un-authenticated means of completely disabling monitoring of a host, and can be used to remove all traces of e.g. a system compromise from the Xymon monitor. Note: If messages are sent through a proxy, the IP-address restrictions are of little use, since the messages will appear to originate from the proxy server address. It is therefore strongly recommended that you do NOT include the address of a server running xymonproxy in the list of allowed addresses.

--no-download

Disable the "download" command which can be used by clients to pull files from the Xymon server. The use of these may be seen as a security risk since they allow file downloads.

--ack-each-color

By default, sending an ACK for a yellow status stops alerts from being sent while the status remains yellow or red. A status change from yellow to red will not re-enable alerts - the ACK covers all non-green statuses. With this option, an ACK is valid only for the color of the status when the ACK was sent. So an ACK for a yellow status is ignored if the status later changes to red, but an ACK for a red status covers both yellow and red.

Note: An ACK for a red status will clear any existing yellow acks. This means that a long-lived ack for yellow is lost when you send a short-lived ack for red. Hence alerts will restart when the red ack expires, even if the status by then has changed to yellow.

--ack-log=FILENAME

Log acknowledgements created on the Critical Systems page to FILENAME. NB, acknowledgements created by the Acknowledge Alert CGI are automatically written to acknowledge.log in the Xymon server log directory. Alerts from the Critical Systems page can be directed to the same log.

--debug

Enable debugging output.

--dbghost=HOSTNAME

For troubleshooting problems with a specific host, it may be useful to track the exact communications from a single host. This option causes xymond to dump all traffic from a single host to the file "/tmp/xymond.dbg".

## HOW ALERTS TRIGGER
When a status arrives, xymond matches the old and new color against the "alert" colors (from the "ALERTCOLORS" setting) and the "OK" colors (from the "OKCOLORS" setting). The old and new color falls into one of three categories:

OK: The color is one of the "OK" colors (e.g. "green").

ALERT: The color is one of the "alert" colors (e.g. "red").

UNDECIDED: The color is neither an "alert" color nor an "OK" color (e.g. "yellow").

If the new status shows an ALERT state, then a message to the xymond_alert(8) module is triggered. This may be a repeat of a previous alert, but xymond_alert(8) will handle that internally, and only send alert messages with the interval configured in alerts.cfg(5).

If the status goes from a not-OK state (ALERT or UNDECIDED) to OK, and there is a record of having been in a ALERT state previously, then a recovery message is triggered.

The use of the OK, ALERT and UNDECIDED states make it possible to avoid being flooded with alerts when a status flip-flops between e.g yellow and red, or green and yellow.

## CHANNELS
A lot of functionality in the Xymon server is delegated to "worker modules" that are fed various events from xymond via a "channel". Programs access a channel using IPC mechanisms - specifically, shared memory and semaphores - or by using an instance of the xymond_channel(8) intermediate program. xymond_channel enables access to a channel via a simple file I/O interface.

A skeleton program for hooking into a xymond channel is provided as part of Xymon in the xymond_sample(8) program.

The following channels are provided by xymond:

status This channel is fed the contents of all incoming "status" and "summary" messages.

stachg This channel is fed information about tests that change status, i.e. the color of the status-log changes.

page This channel is fed information about tests where the color changes between an alert color and a non-alert color. It also receives information about "ack" messages.

data This channel is fed information about all "data" messages.

notes This channel is fed information about all "notes" messages.

enadis This channel is fed information about hosts or tests that are being disabled or enabled.

client This channel is fed the contents of the client messages sent by Xymon clients installed on the monitored servers.

clichg This channel is fed the contents of a host client messages, whenever a status for that host goes red, yellow or purple.

Information about the data stream passed on these channels is in the Xymon source-tree, see the "xymond/new-daemon.txt" file.

## SIGNALS
SIGHUP

Re-read the hosts.cfg configuration file.

SIGUSR1

Force an immediate dump of the checkpoint file.

## BUGS
Timeout of incoming connections are not strictly enforced. The check for a timeout only triggers during the normal network handling loop, so a connection that should timeout after N seconds may persist until some activity happens on another (unrelated) connection.

## FILES
If ghost-handling is enabled via the "--ghosts" option, the hosts.cfg file is read to determine the names of all known hosts.

## SEE ALSO
xymon(7), xymonserver.cfg(5).


package: xymon-man

title: xymond_alert(8)

text:
# xymond_alert(8)

## NAME
xymond_alert - xymond worker module for sending out alerts

## SYNOPSIS
xymond_channel --channel=page xymond_alert [options]

## DESCRIPTION
xymond_alert is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives xymond page- and ack-messages from the "page" channel via stdin, and uses these to send out alerts about failed and recovered hosts and services.

The operation of this module is controlled by the alerts.cfg(5) file. This file holds the definition of rules and recipients, that determine who gets alerts, how often, for what servers etc.

## OPTIONS
--config=FILENAME

Sets the filename for the alerts.cfg file. The default value is "etc/alerts.cfg" below the Xymon server directory.

--dump-config

Dumps the configuration after parsing it. May be useful to track down problems with configuration file errors.

--checkpoint-file=FILENAME

File where the current state of the xymond_alert module is saved. When starting up, xymond_alert will also read this file to restore the previous state.

--checkpoint-interval=N

Defines how often (in seconds) the checkpoint-file is saved.

--cfid

If this option is present, alert messages will include a line with "cfid:N" where N is the linenumber in the alerts.cfg file that caused this message to be sent. This can be useful to track down problems with duplicate alerts.

--test HOST SERVICE [options]

Shows which alert rules matches the given HOST/SERVICE combination. Useful to debug configuration problems, and see what rules are used for an alert. The possible options are:

--color=COLORNAME The COLORNAME parameter is the color of the alert: red, yellow or purple.

--duration=MINUTES The MINUTES parameter is the duration of the alert in minutes.

--group=GROUPNAME The GROUPNAME parameter is a groupid string from the analysis.cfg file.

--time=TIMESTRING The TIMESTRING parameter is the time-of-day for the alert, expressed as an absolute time in the epoch format (seconds since Jan 1 1970). This is easily obtained with the GNU date utility using the "+%s" output format.

--trace=FILENAME

Send trace output to FILENAME, This allows for more detailed analysis of how alerts trigger, without having the full debugging enabled.

--debug

Enable debugging output.

## HOW XYMON DECIDES WHEN TO SEND ALERTS
The xymond_alert module is responsible for sending out all alerts. When a status first goes to one of the ALERTCOLORS, xymond_alert is notified of this change. It notes that the status is now in an alert state, and records the timestamp when this event started, and adds the alert to the list statuses that may potentially trigger one or more alert messages.

This list is then matched against the alerts.cfg configuration. This happens at least once a minute, but may happen more often. E.g. when status first goes into an alert state, this will always trigger the matching to happen.

When scanning the configuration, xymond_alert looks at all of the configuration rules. It also checks the DURATION setting against how long time has elapsed since the event started - i.e. against the timestamp logged when xymond_alert first heard of this event.

When an alert recipient is found, the alert is sent and it is recorded when this recipient is due for his next alert message, based on the REPEAT setting defined for this recipient. The next time xymond_alert scans the configuration for what alerts to send, it will still find this recipient because all of the configuration rules are fulfilled, but an alert message will not be generated until the repeat interval has elapsed.

It can happen that a status first goes yellow and triggers an alert, and later it goes red - e.g. a disk filling up. In that case, xymond_alert clears the internal timer for when the next (repeat) alert is due for all recipients. You generally want to be told when something that has been in a warning state becomes critical, so in that case the REPEAT setting is ignored and the alert is sent. This only happens the first time such a change occurs - if the status switches between yellow and red multiple times, only the first transition from yellow->red causes this override.

When an status recovers, a recovery message may be sent - depending on the configuration - and then xymond_alert forgets everything about this status. So the next time it goes into an alert state, the entire process starts all over again.

## ENVIRONMENT
MAIL

The first part of a command line used to send out an e-mail with a subject, typically set to "/usr/bin/mail -s" . xymond_alert will add the subject and the mail recipients to form the command line used for sending out email alerts.

MAILC

The first part of a command line used to send out an e-mail without a subject. Typically this will be "/usr/bin/mail". xymond_alert will add the mail recipients to form the command line used for sending out email alerts.

## FILES
~xymon/server/etc/alerts.cfg

## SEE ALSO
alerts.cfg(5), xymond(8), xymond_channel(8), xymon(7)


title: xymond_capture(8)

text:
# xymond_capture(8)

## NAME
xymond_capture - catch selected messages from a xymond channel

## SYNOPSIS
xymond_channel --channel=status xymond_capture [options]

## DESCRIPTION
xymond_capture is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives messages from xymond via stdin and filters them to select messages based on the hostname, testname or color of the status. By default the resulting messages are printed on stdout, but they can also be fed into a command for further processing.

xymond_capture supports the status, data, client and hostdata channels.

## OPTIONS
--hosts=PATTERN

Select messages only from hosts matching PATTERN (regular expression).

--exhosts=PATTERN

Exclude messages from hosts matching PATTERN. If used with the --hosts option, then the hostname must match the --hosts pattern, but NOT the --exhosts pattern.

--tests=PATTERN

Select messages only from tests matching PATTERN (regular expression).

--extests=PATTERN

Exclude messages from tests matching PATTERN. If used with the --tests option, then the testname must match the --tests pattern, but NOT the --extests pattern.

--colors=COLOR[,color]

Select messages based on the color of the status message. Multiple colors can be listed, separated by comma. Default: Accept all colors.

--batch-command=COMMAND

Instead of printing the messages to stdout, feed them to COMMAND on stdin. COMMAND can be any command which accepts the mssage on standard input.

--batch-timeout=SECONDS

Collect messages until no messages have arrived in SECONDS seconds, before sending them to the --batch-command COMMAND.

--client

Capture data from the "client" channel instead of the default "status" channel.

--debug

Enable debugging output.

## SEE ALSO
xymond_channel(8), xymond(8), xymon(7)


title: xymond_channel(8)

text:
# xymond_channel(8)

## NAME
xymond_channel - Feed a xymond channel to a worker module

## SYNOPSIS
xymond_channel --channel=CHANNEL [options] workerprogram [worker-options]

## DESCRIPTION
xymond_channel hooks into one of the xymond(8) channels that provide information about events occurring in the Xymon system. It retrieves messages from the xymond daemon, and passes them on to the workerprogram on the STDIN (file descripter 1) of the worker program. Worker programs can then handle messages as they like.

A number of worker programs are shipped with xymond, e.g. xymond_filestore(8) xymond_history(8) xymond_alert(8) xymond_rrd(8)

If you want to write your own worker module, a sample worker module is provided as part of the xymond distribution in the xymond_sample.c file. This illustrates how to easily fetch and parse messages.

## OPTIONS
xymond_channel accepts a few options.

--channel=CHANNELNAME

Specifies the channel to receive messages from, only one channel can be used. This option is required. The following channels are available:

"status" receives all Xymon status- and summary-messages

"stachg" receives information about status changes

"page" receives information about statuses triggering alerts

"data" receives all Xymon "data" messages

"notes" receives all Xymon "notes" messages

"enadis" receives information about hosts being disabled or enabled.

--filter=EXPRESSION

EXPRESSION is a Perl-compatible regular expression. xymond_channel will match the first line of each message against this expression, and silently drops any message that does not match the expression. Especially useful for custom worker modules and during testing, to limit the amount of data that the module must process.

Note that messages for "logrotate", "shutdown", "drophost", "renamehost", "droptest" and "renametest" are always forwarded by xymond_channel, whether they match the filter or not.

--msgtimeout=TIMEOUT

Modify the default timeout (30 seconds) for the worker module to handle a message. If a message is not handled within this time, it is considered lost. You normally do not have to modify this unless you have an extremely busy server.

--daemon

xymond_channel is normally started by xymonlaunch(8) as a task defined in the tasks.cfg(5) file. If you are not using xymonlaunch, then starting xymond_channel with this option causes it to run as a stand-alone background task.

--pidfile=FILENAME

If running as a stand-alone daemon, xymond_channel will save the process-ID of the daemon in FILENAME. This is useful for automated startup- and shutdown- scripts.

--env=FILENAME

Loads the environment variables defined in FILENAME before starting xymond_channel. This is normally used only when running as a stand-alone daemon; if xymond_channel is started by xymonlaunch, then the environment is controlled by the task definition in the tasks.cfg(5) file.

--log=FILENAME

Redirect output to this log-file.

--md5 / --no-md5

Enable/disable checksumming of messages passed from xymond_channel to the worker module. This may be useful if you suspect that data may be corrupted, e.g. when sent to a remote worker module. Note that enabling this may break communication with old versions of Xymon worker modules. Default: Disabled.

--debug

Enable debugging output.

## FILES
This program does not use any configuration files.

## SEE ALSO
xymond(8), xymon(7)


title: xymond_client(8)

summary: xymond worker module for client data

text:
# xymond_client(8)

## NAME
xymond_client - xymond worker module for client data

## SYNOPSIS
xymond_channel --channel=client xymond_client [options]

## DESCRIPTION
xymond_client is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives xymond client messages sent from systems that have the the Xymon client installed, and use the client data to generate the Xymon status messages for the cpu-, disk-, memory- and procs-columns. It also feeds Xymon data messages with the netstat- and vmstat-data collected by the client.

When generating these status messages from the client data, xymond_client will use the configuration rules defined in the analysis.cfg(5) file to determine the color of each status message.

## OPTIONS
--clear-color=COLOR

Define the color used when sending "msgs", "files" or "ports" reports and there are no rules to check for these statuses. The default is to show a "clear" status, but some people prefer to have it "green". If you would rather prefer not to see these status columns at all, then you can use the "--no-clear-msgs", "--no-clear-files" and "--no-clear-ports" options instead.

--no-clear-msgs

If there are no logfile checks, the "msgs" column will show a "clear" status. If you would rather avoid having a "msgs" column, this option causes xymond_client to not send in a clear "msgs" status.

--no-clear-files

If there are no file checks, the "files" column will show a "clear" status. If you would rather avoid having a "files" column, this option causes xymond_client to not send in a clear "files" status.

--no-clear-ports

If there are no port checks, the "ports" column will show a "clear" status. If you would rather avoid having a "ports" column, this option causes xymond_client to not send in a clear "ports" status.

--no-ps-listing

Normally the "procs" status message includes the full process-listing received from the client. If you prefer to just have the monitored processes shown, this option will turn off the full ps-listing.

--no-port-listing

Normally the "ports" status message includes the full netstat-listing received from the client. If you prefer to just have the monitored ports shown, this option will turn off the full netstat-listing.

--no-cpu-listing

Normally the "cpu" status message includes the full cpu-listing received from the client. If you prefer to just have the monitored cpu load shown, this option will turn off the full cpu-listing.

--uptime-status

Generate a separate "uptime" status column. The uptime is normally just reported in the "cpu" status column, but if you would like a separate status column for the uptime, you can use this option. It is useful if you want to generate an alert in case of a reboot, without having this alert mixed in with the cpu load alerts.

--config=FILENAME

Sets the filename for the analysis.cfg file. The default value is "etc/analysis.cfg" below the Xymon server directory.

--unknownclientosok

Expect and attempt to parse clients with unknown CLIENTOS types. Useful if you're submitting custom host responses with file or msgs data that you'd like to parse.

--dump-config

Dumps the configuration after parsing it. May be useful to track down problems with configuration file errors.

--test

Starts an interactive session where you can test the analysis.cfg configuration.

--collectors=COLLECTOR1[,COLLECTOR2,...]

Limit the set of collector modules that xymond_client will handle. This is not normally used except for running experimental versions of the program.

--debug

Enable debugging output.

## FILES
~xymon/server/etc/analysis.cfg

## BUGS
The "disk" status cannot handle filesystems containing whitespace in the filesystem (device) name.

## SEE ALSO
analysis.cfg(5), xymond(8), xymond_channel(8), xymon(7)


title: xymond_distribute(8)

text:
# xymond_distribute(8)

## NAME
xymond_distribute - xymond worker module for distributing commands

## SYNOPSIS
xymond_channel --channel=enadis xymond_distribute [options]

## DESCRIPTION
xymond_distribute is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It is used if you have multiple Xymon servers running in a master/slave configuration. xymond_distribute runs on the master server and receives "drop", "rename", "enable" and "disable" messages from xymond. xymond_distribute then forwards these to the other Xymon servers as standard xymon messages. So if a user on the master Xymon server disables a red status, xymond_distribute will forward this to the other Xymon servers so that the change happens everywhere.

NOTE: xymond_distribute does not check to see if a message has already been forwarded, so you can easily create forwarding loops.

## OPTIONS
--peer=HOSTNAME

The peer that messages are forwarded to. If you have multiple peers, repeat this option.

--debug

Enable debugging output.

## SEE ALSO
xymond_channel(8), xymond(8), xymon(7)


title: xymond_filestore(8)

text:
# xymond_filestore(8)

## NAME
xymond_filestore - xymond worker module for storing Xymon data

## SYNOPSIS
xymond_channel --channel=status xymond_filestore --status [options]

xymond_channel --channel=data xymond_filestore --data [options]

xymond_channel --channel=notes xymond_filestore --notes [options]

xymond_channel --channel=enadis xymond_filestore --enadis [options]

## DESCRIPTION
xymond_filestore is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives xymond messages from a xymond channel via stdin, and stores these in the filesystem in a manner that is compatible with the Big Brother daemon, bbd.

This program can be started multiple times, if you want to store messages for more than one channel.

## OPTIONS
--status

Incoming messages are "status" messages, they will be stored in the $XYMONRAWSTATUSDIR/ directory. If you are using xymon(7) throughout your Xymon server, you will not need to run this module to save status messages, unless you have a third-party add-on that reads the status-logs directly. This module is NOT needed to get trend graphs, you should run the xymond_rrd(8) module instead.

--data

Incoming messages are "data" messages, they will be stored in the $XYMONDATADIR directory. This module is not needed, unless you have a third-party module that processes the data-files. This module is NOT needed to get trend graphs, you should run the xymond_rrd(8) module instead.

--notes

Incoming messages are "notes" messages, they will be stored in the $XYMONNOTESDIR directory. This modules is only needed if you want to allow people to remotely update the notes-files available on the Xymon webpages.

--enadis

Incoming messages are enable/disable messages, they will update files in the $XYMONDISABLEDDIR directory. This is only needed if you have third-party add-ons that use these files.

--dir=DIRECTORY

Overrides the default output directory.

--html

Used together with "--status". Tells xymond_filestore to also save an HTML version of the status-log. Should not be used unless you must run with "XYMONLOGSTATUS=static".

--htmldir=DIRECTORY

The directory where HTML-versions of the status logs are stored. Default: $XYMONHTMLSTATUSDIR

--htmlext=.EXT

Set the filename extension for generated HTML files. By default, HTML files are saved with a ".html" extension.

--multigraphs=TEST1[,TEST2]

This causes xymond_filestore to generate HTML status pages with links to service graphs that are split up into multiple images, with at most 5 graphs per image. If not specified, only the "disk" status is split up this way.

--only=test[,test,test]

Save status messages only for the listed set of tests. This can be useful if you have an external script that needs to parse some of the status logs, but you do not want to save all status logs.

--debug

Enable debugging output.

## FILES
This module does not rely on any configuration files.

## SEE ALSO
xymond_channel(8), xymond_rrd(8), xymond(8), xymon(7)


title: xymond_history(8)

text:
# xymond_history(8)

## NAME
xymond_history - xymond worker module for logging status changes

## SYNOPSIS
xymond_channel --channel=stachg xymond_history [options]

## DESCRIPTION
xymond_history is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives xymond status-change messages from the "stachg" channel via stdin, and uses these to update the history logfiles in a manner that is compatible with the standard Big Brother daemon, bbd.

## OPTIONS
--histdir=DIRECTORY

The directory for the history files. If not specified, the directory given by the XYMONHISTDIR environment is used.

--histlogdir=DIRECTORY

The directory for the historical status-logs. If not specified, the directory given by the XYMONHISTLOGS environment is used.

--minimum-free=N

Sets the minimum percentage of free filesystem space on the $XYMONHISTLOGS directory. If there is less than N% free space, xymond_history will not save the detailed status-logs. Default: 5

--pidfile=FILENAME

xymond_history writes the process-ID it is running with to this file. This is for use in automated startup scripts. The default file is $XYMONSERVERLOGS/xymond_history.pid.

--debug

Enable debugging output.

## ENVIRONMENT
XYMONALLHISTLOG

This environment variable controls if the $XYMONHISTDIR/allevents logfile is updated. This file is used by the event-log display on the nongreen html page and the eventlog-webpage, among other things. You can disable it by setting XYMONALLHISTLOGS=FALSE, but this is not recommended.

XYMONHOSTHISTLOG

This environment variable controls if the $XYMONHISTDIR/HOSTNAME logfile is updated. This file holds a list of all status changes seen for a single host, but is not used by any of the standard Xymon tools. If you do not want to save this, you can disable it by setting XYMONHOSTHISTLOG=FALSE.

SAVESTATUSLOG

This environment variable controls if the historical status-logs are saved whenever a status change occurs. These logfiles are stored in the $XYMONHISTLOGS directory, and are used for the detailed log-display of a status from the Xymon "History" page. If you do not want to save these, you can disable it by setting SAVESTATUSLOG=FALSE. If you want to save all except some specific logs, use SAVESTATUSLOG=TRUE,!TEST1[,!TEST2...] If you want to save none except some specific logs, use SAVESTATUSLOG=FALSE,TEST1[,TEST2...]

NOTE: Status logs will not be saved if there is less than 5% free space on the filesystem hosting the $XYMONHISTLOGS directory. The threshold can be tuned via the "--minimum-free" option.

## FILES
This module does not rely on any configuration files.

## SEE ALSO
xymond_channel(8), xymond(8), xymon(7)


title: xymond_hostdata(8)

text:
# xymond_hostdata(8)

## NAME
xymond_hostdata - xymond worker module for storing historical client data

## SYNOPSIS
xymond_channel --channel=clichg xymond_hostdata

## DESCRIPTION
xymond_hostdata is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. Whenever a status column in Xymon changes to an alert state (usually red, yellow or purple), this module receives a copy of the latest Xymon client data sent by the host, and stores it on disk. This allows you to review all of the data collected by the Xymon client on the server around the time that a problem occurred. This can make troubleshooting incidents easier by providing a snapshot of the host status shortly before a problem became apparent.

Note: This module requires that xymond(8) is launched with the "--store-clientlogs" option enabled.

## OPTIONS
--minimum-free=N

Sets the minimum percentage of free filesystem space on the $CLIENTLOGS directory. If there is less than N% free space, xymond_hostdata will not save the data. Default: 5

--debug

Enable debugging output.

## FILES
All of the host data are stored in the $CLIENTLOGS directory, by default this is the $XYMONVAR/hostdata/ directory.

## SEE ALSO
xymond(8), xymond_channel(8), xymon(7)


title: xymond_rrd(8)

text:
# xymond_rrd(8)

## NAME
xymond_rrd - xymond worker module for updating Xymon RRD files

## SYNOPSIS
xymond_channel --channel=status xymond_rrd [options]

xymond_channel --channel=data xymond_rrd [options]

## DESCRIPTION
xymond_rrd is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives "status" and "data" messages from xymond via stdin, and updates the RRD databases used to generate trend-graphs.

Clients can send data to Xymon using both status- and data- messages. So you will normally run two instances of this module, once for the "status" channel and once for the "data" channel.

xymond_rrd understands data sent by the LARRD 0.43c client-side scripts (the so-called "bottom-feeder" scripts). So you still want to install the LARRD bottom-feeders on the clients you monitor.

Note: For certain types of data, the RRD files used by Xymon are imcompatible with those generated by the Big Brother LARRD add-on. See the COMPATIBILITY section below.

## OPTIONS
--debug

Enable debugging output.

--rrddir=DIRECTORY

Defines the directory where the RRD-files are stored. xymond_rrd will use the location pointed to by the XYMONRRDS environment if this option is not present.

--no-cache

xymond_rrd by default caches updates to the RRD files, to reduce the disk I/O needed for storing the RRD data. Data is collected for a 30 minute period before being committed to disk in one update. This option disables caching of the data, so that data is stored on disk immediately.

--processor=FILENAME

xymond_rrd can send a parallel copy of all RRD updates to a single external process as a stream on its STDIN. The data will be in a format similar to that used by rrdupdate(1): <rrdtemplate> ts:<rrdvalue(s)> host <rrdparameters> If the process exits, xymond_rrd will re-launch it.

--extra-script=FILENAME

Defines the script that is run to get the RRD data for tests that are not built into xymond_rrd. You must also specify which tests are handled by the external script in the --extra-tests option. This option can only be given once, so the script must handle all of the external test-data. See the CUSTOM RRD DATA section below. Note that this is NOT needed if your custom graphs are generated by the NCV (Name Colon Value) module described below, it is only required for data where you have a custom script to parse the status message and extract the data that is put into the graph.

--extra-tests=TEST[,TEST]

List of testnames that are handled by the external script. See the CUSTOM RRD DATA section below. Note that NCV graphs should NOT be listed here, but in the TEST2RRD environment variable - see below.

--no-rrd

Disable the actual writing of RRD files. This is only really useful if you send all of the data destined for the RRD files to an external processor (the --extra-script or --processor options).

## ENVIRONMENT
TEST2RRD

Defines the mapping between a status-log columnname and the corresponding RRD database format. This is normally defined in the xymonserver.cfg(5) file.

XYMONRRDS

Default directory where RRD files are stored.

NCV_testname

Defines the types of data collected by the "ncv" module in xymond_rrd. See below for more information.

SPLITNCV_testname

The same as NCV_testname, but keeps the data into separate files. That is, it creates one rrd file per "NAME : value" line found in the status message. It is useful when the list of NCV lines is varying.

TRACKMAX

Comma-separated list of columnname for which you want to keep the maximum values along with the default average values. This only works

for the NCV backend.

## COLLECTED DATA
The following RRD-file datasets are generated by xymond_rrd:

la

Records the CPU load average. Data is collected from the "cpu" status report. Requires that a Xymon client is running on the monitored server.

disk

Records the disk utilization. Data is collected from the "disk" status report. Requires that a Xymon-compatible client is running on the monitored server.

memory

Records memory- and swap-utilization. Data is collected from the "memory" status report. If no "memory" status is reported, it will use the data from the Win32 client "cpu" status report to generate this dataset. Requires that a Xymon-compatible client is running on the monitored server.

netstat

Records TCP and UDP statistics. Data is collected from the "netstat" status report; however, this data is often sent via the Xymon "data" protocol, so there need not be a "netstat" column visible on the Xymon display. To get these data, the LARRD netstat bottom-feeder script must be running on the monitored server.

vmstat

Records system performance metrics from the "vmstat" command. Data is collected from the "vmstat" status report; however, this data is often sent via the Xymon "data" protocol, so there need not be a "vmstat" column visible on the Xymon display. To get these data, the LARRD vmstat bottom-feeder script must be running on the monitored server.

tcp

Response-time metrics from all of the Xymon network tests are recorded in the "tcp" RRD.

apache

Apache server performance metrics, taken from the "apache" data report. See the description of the apache keyword in hosts.cfg(5) for details.

sendmail

Sendmail server performance metrics, taken from the "mailstats" output. To get these data, the LARRD sendmail bottom-feeder script must be running on the monitored server.

mailq

Mail queue size. To get these data, the LARRD nmailq bottom-feeder script must be running on the monitored server.

bea

BEA Weblogic performance data. This is an experimental set of data collected from BEA Weblogic servers via SNMP, by the "beastats" tool included with Xymon.

iishealth

IIS webserver performance data, collected by the "iishealth" script. This script is a client-side add-on available from the www.deadcat.net archive.

temperature

Temperature data, collected with the temperature script from www.deadcat.net. To get these data, the temperature script must be running on the monitored server.

ntpstat

Tracks the deviation between the local system time and an NTP server, using the output from the "ntpq -c rv" command. A simple script to collect these data is included in the Xymon contrib/ directory.

citrix

Tracks the number of active sessions on a Citrix server using the "query session" command. An extension for the BBNT client that generates data for this graph is in the Xymon contrib/ directory.

## CUSTOM RRD DATA IN NAME-COLON-VALUE (NCV) FORMAT
Many data-collection scripts report data in the form "NAME : value" or "NAME = value". So a generic module in xymond_rrd allows for easy tracking of this type of data.

The "ncv" module will automatically detect all occurrences of a "NAME : value" or "NAME = value" string in a status message, and generate an RRD file holding all of the name/value data found in the message (unless you use SPLITNCV, see above). The colon- or equal-sign must be present - if there is only whitespace, this module will fail.

Only the valid letters (A-Z, a-z) and digits (0-9) are used in the dataset names; whitespace and other characters are stripped off automatically. Only the first 19 characters of a dataset name are used (this is an RRD limitation). Underscore '_' is not allowed, even though RRDtool permits this, and will be stripped from the name.

When using the alternative SPLITNCV_testname, the dataset name is not limited in length, and non-valid characters are changed to underscores instead of being stripped off. The dataset inside the resulting rrd file is always "lambda".

Note that each "NAME : value" must be on a line by itself. If you have a custom script generating the status- or data-message that is fed into the NCV handler, make sure it inserts a newline before each of the data-items you want to track.

Any lines in the status message prepended with a "<!-- ncv_skip -->" will be skipped by the module. This can be used to prevent unneeded RRD files from an existing dataset from being created.

A line prepended with a "<!-- ncv_skipstart -->" will be ignored, along with all subsequent lines until a line starting with "<!-- ncv_skipend -->" is found, at which point processing will resume. This can be used to ignore explanatory or other text with a mostly-ncv message.

"<!-- ncv_ignore -->" can be used to ignore certain text at the beginning of a line, up until a closing '</-->' tag on the same line, at which point the line will continue to be processed as usual. Wrapping is not supported; but skipstart/skipend can be used to handle multiple lines.

A bare "<!-- ncv_end -->" on its own line will stop further NCV processing of that message.

All of these ncv_ terms are case-sensitive. Note that if you have full control over your NCV output, it is most efficient to have NCV data near the top of your message and use "<!-- ncv_end -->" once your data is complete.

To enable the ncv module for a status, add a "COLUMNNAME=ncv" to the TEST2RRD setting and the COLUMNNAME to the GRAPHS setting in xymonserver.cfg(5) , then restart Xymon. Xymon will now send all status-messages for the column COLUMNNAME through the xymond_rrd ncv-handler.

The name of the RRD file will be COLUMNNAME.rrd. When using SPLITNCV, the name of the RRD file will be COLUMNAME,DATASETNAME.rrd.

By default, all of the datasets are generated as the RRD type "DERIVE" which works for all types of monotonically increasing counters. If you have data that are of the type GAUGE, you can override the default via an environment variable NCV_COLUMNNAME (or SPLITNCV_COLUMNAME).

E.g. if you are using the bb-mysqlstatus script from www.deadcat.net to collect data about your MySQL server, it generates a report in the column called "mysql". One data item is the average number of queries/second, which must be logged in the RRD file as type "GAUGE". To do that, add the following to xymonserver.cfg:

NCV_mysql="Queriespersecondavg:GAUGE"

If you have multiple datasets that you myst define, add them to the environment variable separated by commas, e.g.

NCV_mysql="Uptime:NONE,Queriespersecondavg:GAUGE"

The dataset type "NONE" used above causes xymond_rrd to ignore this data, it is not included in the RRD file.

You can use "*" as the dataset name to match all datasets not listed. E.g.

NCV_weather="Rain:DERIVE,*:GAUGE"

will cause the "Rainfall" dataset to be of type DERIVE, and all others of type GAUGE. If you want to track only a few of the variables in your data, you can use "*:NONE" to drop any dataset not explicitly listed.

For a more detailed "how to" description, see the on-line HTML documentation of "How to create graph custom data" available in the Help menu section on your Xymon server.

## SENDING METRIC DATA TO AN ADDITIONAL PROCESS
xymond_rrd provides a mechanism to send a copy of isolated metric data to a single external processor for further processing. This can be used to inject metric data that xymond_rrd has prepared into other storage systems, such as OpenTSDB, graphite, etc. The data is printed in a format nearly suitable for injection using rrdupdate(1) and easily transformable to other formats. If the process exits, xymond_rrd will re-launch it automatically.

## CUSTOM RRD DATA VIA SCRIPTS
xymond_rrd provides a simple mechanism for adding custom graphs to the set of data collected on your Xymon server. By adding the "--extra-script" and "--extra-tests" options, data reported to Xymon from selected tests are passed to an external script, which can define the RRD data-sets to store in an RRD file.

NOTE: For performance reasons, you should not use this mechanism for large amounts of data. The overhead involved in storing the received message to disk and launching the script is significantly larger than the normal xymond_rrd overhead. So if you have a large number of reports for a given test, you should consider implementing it in C and including it in the xymond_rrd tool or writing a separate stream listener that injects appropriate "trends" data messages back to xymond.

Apart from writing the script, You must also add a section to graphs.cfg(5) so that showgraph.cgi(1) knows how to generate the graph from the data stored in the RRD file. To make the graphs actually show up on the status-page and/or the "trends" page, add the name of the new graph to the TEST2RRD and/or GRAPHS setting in xymonserver.cfg(5).

The script is invoked for each message that arrives, where the test-name matches one of the testnames given in the "--extra-tests" option. The script receives three command-line parameters:

Hostname

The name of the host reporting the data.

Testname

The name of the test being reported.

Filename

File containing the data that was reported. This file is generated for you by xymond_rrd, and is also deleted automatically after your script is finished with it.

The script must process the data that is reported, and generate the following output:

RRD data-set definitions

For each dataset that the RRD file holds, a line beginning with "DS:" must be output. If multiple data-sets are used, print one line for each dataset.

Data-set definitions are described in the rrdcreate(1) documentation, but a common definition for e.g. tracking the number of users logged on would be "DS:users:GAUGE:600:0:U". "users" is the name of the dataset, "GAUGE" is the datatype, "600" is the longest time allowed between updates for the data to be valid, "0" is the minimum value, and "U" is the maximum value (a "U" means "unknown").

RRD filename

The name of the RRD file where the data is stored. Note that Xymon stores all RRD files in host-specific directories, so unlike LARRD you should not include the hostname in the name of the RRD file.

RRD values

One line, with all of the data values collected by the script. Data-items are colon-delimited and must appear in the same sequence as your data-set definitions, e.g. if your RRD has two datasets with the values "5" and "0.4" respectively, then the script must output "5:0.4" as the RRD values.

In some cases it may be useful to define a dataset even though you will not always have data for it. In that case, use "U" (unknown) for the value. If you want to store the data in multiple RRD files, the script can just print out more sequences of data-set definitions, RRD filenames and RRD values. If the data-set definitions are identical to the previous definition, you need not print the data-set definitions again - just print a new RRD filename and value.

The following sample script for tracking weather data shows how to use this mechanism. It assumes the status message include lines like these:

```
green Weather in Copenhagen is FAIR
Temperature: 21 degrees Celsius
Wind: 4 m/s
Humidity: 72 %
Rainfall: 5 mm since 6:00 AM
```

A shell-script to track all of these variables could be written like this:

```
#!/bin/sh
# Input parameters: Hostname, testname (column), and messagefile
HOSTNAME="$1"
TESTNAME="$2"
FNAME="$3"
if [ "$TESTNAME" = "weather" ]
then
	# Analyze the message we got
	TEMP=`grep "^Temperature:" $FNAME | awk '{print $2}'`
	WIND=`grep "^Wind:" $FNAME | awk '{print $2}'`
	HMTY=`grep "^Humidity:" $FNAME | awk '{print $2}'`
	RAIN=`grep "^Rainfall:" $FNAME | awk '{print $2}'`
	# The RRD dataset definitions
	echo "DS:temperature:GAUGE:600:-30:50"
	echo "DS:wind:GAUGE:600:0:U"
	echo "DS:humidity:GAUGE:600:0:100"
	echo "DS:rainfall:DERIVE:600:0:100"
	# The filename
	echo "weather.rrd"
	# The data
	echo "$TEMP:$WIND:$HMTY:$RAIN"
fi
exit 0
```

## COMPATIBILITY
Some of the RRD files generated by xymond_rrd are incompatible with the files generated by the Big Brother LARRD add-on:

vmstat

The vmstat files with data from Linux based systems are incompatible due to the addition of a number of new data-items that LARRD 0.43 do not collect, but xymond_rrd does. This is due to changes in the output from the Linux vmstat command, and changes in the way e.g. system load metrics are reported.

netstat

All netstat files from LARRD 0.43 are incompatible with xymond_rrd. The netstat data collected by LARRD is quite confusing: For some types of systems LARRD collects packet-counts, for others it collects byte- counts. xymond_rrd uses a different RRD file-format with separate counters for packets and bytes and tracks whatever data the system is reporting.

## SEE ALSO
xymond_channel(8), xymond(8), xymonserver.cfg(5), xymon(7)


title: xymond_sample(8)

summary: example of a xymond worker module

text:
# xymond_sample(8)

## NAME
xymond_sample - example of a xymond worker module

## SYNOPSIS
xymond_channel --channel=status xymond_sample [options]

## DESCRIPTION
xymond_sample is a worker module for xymond, and as such it is normally run via the xymond_channel(8) program. It receives messages from xymond via stdin, and simply displays these on stdout. It can be used with all types of xymond channels.

xymond_sample is not designed to actually run, except as a demonstration. The purpose of this tool is to show how xymond worker modules can be implemented to handle different tasks that need to hook into the xymond processing.

## OPTIONS
--timeout=N

Read messages with a timeout of N seconds.

--debug

Enable debugging output.

## SEE ALSO
xymond_channel(8), xymond(8), xymon(7)


xymonfetch

title: xymonfetch(8)

summary: fetch client data from passive clients

text:
# xymonfetch(8)

## NAME
xymonfetch - fetch client data from passive clients

## SYNOPSIS
xymonfetch [--server=XYMON.SERVER.IP] [options]

## DESCRIPTION
This utility is used to collect data from Xymon clients.

Normally, Xymon clients will themselves take care of sending all of their data directly to the Xymon server. In that case, you do not need this utility at all. However, in some network setups clients may be prohibited from establishing a connection to an external server such as the Xymon server, due to firewall policies. In such a setup you can configure the client to store all of the client data locally by enabling the msgcache(8) utility on the client, and using xymonfetch on the Xymon server to collect data from the clients.

xymonfetch will only collect data from clients that have the pulldata tag listed in the hosts.cfg(5) file. The IP-address listed in the hosts.cfg file must be correct, since this is the IP-address where xymonfetch will attempt to contact the client. If the msgcache daemon is running on a non-standard IP-address or portnumber, you can specify the portnumber as in pulldata=192.168.1.2:8084 for contacting the msgcache daemon using IP 192.168.1.2 port 8084. If the IP-address is omitted, the default IP in the hosts.cfg file is used. If the port number is omitted, the portnumber from the XYMONDPORT setting in xymonserver.cfg(5) is used (normally, this is port 1984).

## OPTIONS
--server=XYMON.SERVER.IP

Defines the IP address of the Xymon server where the collected client messages are forwarded to. By default, messages are sent to the loopback address 127.0.0.1, i.e. to a Xymon server running on the same host as xymonfetch.

--interval=N

Sets the interval (in seconds) between polls of a client. Default: 60 seconds.

--id=N

Used when you have a setup with multiple Xymon servers. In that case, you must run xymonfetch on each of the Xymon servers, with xymonfetch instance using a different value of N. This allows several Xymon servers to pick up data from the clients running msgcache, and msgcache can distinguish between which messages have already been forwarded to which server.

N is a number in the range 1-31.

--log-interval=N

Limit how often xymonfetch will log problems with fetching data from a host, in seconds. Default: 900 seconds (15 minutes). This is to prevent a host that is down or where msgcache has not been started from flooding the xymonfetch logs. Note that this is ignored when debugging is enabled.

--debug

Enable debugging output.

## SEE ALSO
msgcache(8), xymond(8), xymon(7)


xymonlaunch

title: xymonlaunch(8)

text:
# xymonlaunch(8)

## NAME
xymonlaunch - Master program to launch other Xymon programs

## SYNOPSIS
xymonlaunch [options]

## DESCRIPTION
xymonlaunch(8) is the main program that controls the execution and scheduling of all of the components in the Xymon system.

xymonlaunch allows the administrator to add, remove or change the set of Xymon applications and extensions without restarting Xymon - xymonlaunch will automatically notice any changes in the set of tasks, and change the scheduling of activities accordingly.

xymonlaunch also allows the administrator to setup specific logfiles for each component of the Xymon system, instead of getting output from all components logged to a single file.

## OPTIONS
--env=FILENAME

Loads the environment from FILENAME before starting other tools. The environment defined by FILENAME is the default, it can be overridden by the ENVFILE option in tasks.cfg(5)

--config=FILENAME

This option defines the file that xymonlaunch scans for tasks it must launch. A description of this file is in tasks.cfg(5) If not specified, files at /etc/tasks.cfg, /etc/xymon/tasks.cfg, and /etc/xymon-client/clientlaunch.cfg are searched for, as well as ~/server/etc/tasks.cfg.

--log=FILENAME

Defines the logfile where xymonlaunch logs information about failures to launch tasks and other data about the operation of xymonlaunch. Logs from individual tasks are defined in the tasks.cfg file. By default this is logged to stdout.

--pidfile=FILENAME

Filename which xymonlaunch saves its own process-ID to. Commonly used by automated start/stop scripts.

--verbose

Logs the launch of all tasks to the logfile. Note that the logfile may become quite large if you enable this.

--dump

Just dump the contents of the tasks.cfg file after parsing it. Used for debugging.

--debug

Enable debugging output while running.

--no-daemon

xymonlaunch normally detaches from the controlling tty and runs as a background task. This option keeps it running in the foreground.

## STARTING TASKS
xymonlaunch will read the configuration file and start all of the tasks listed there.

If a task completes abnormally (i.e. terminated by a signal or with a non-zero exit status), then xymonlaunch will attempt to restart it 5 times. If it still will not run, then the task is disabled for 10 minutes. This will be logged to the xymonlaunch logfile.

If the configuration file changes, xymonlaunch will re-read it and notice any changes. If a running task was removed from the configuration, then the task is stopped. If a new task was added, it will be started. If the command used for a task changed, or it was given a new environment definition file, or the logfile was changed, then the task is stopped and restarted with the new definition.

## SEE ALSO
tasks.cfg(5), xymon(7)


xymonproxy

title: xymonproxy(8)

summary: Xymon message proxy

text:
# xymonproxy(8)

## NAME
xymonproxy - Xymon message proxy

## SYNOPSIS
xymonproxy [options] --server=$XYMSRV

## DESCRIPTION
xymonproxy(8) is a proxy for forwarding Xymon messages from one server to another. It will typically be needed if you have clients behind a firewall, so they cannot send status messages to the Xymon server directly.

xymonproxy serves three purposes. First, it acts as a regular proxy server, allowing clients that cannot connect directly to the Xymon servers to send data. Although xymonproxy is optimized for handling status messages, it will forward all types of messages, including notes- and data-messages.

Second, it acts as a buffer, smoothing out peak loads if many clients try to send status messages simultaneously. xymonproxy can absorb messages very quickly, but will queue them up internally and forward them to the Xymon server at a reasonable pace.

Third, xymonproxy merges small "status" messages into larger "combo" messages. This can dramatically decrease the number of connections that need to go from xymonproxy to the Xymon server. The merging of messages causes "status" messages to be delayed for up to 0.25 seconds before being sent off to the Xymon server.

## OPTIONS
--server=SERVERIP[:PORT][,SERVER2IP[:PORT]]

Specifies the IP-address and optional portnumber where incoming messages are forwarded to. The default portnumber is 1984, the standard Xymon port number. If you have setup the normal Xymon environment, you can use "--server=$XYMSRV". Up to 3 servers can be specified; incoming messages are sent to all of them (except "config", "query" and "download" messages, which go to the LAST server only). If you have Xymon clients sending their data via this proxy, note that the clients will receive their configuration data from the LAST of the servers listed here. This option is required.

--listen=LOCALIP[:PORT]

Specifies the IP-adress where xymonproxy listens for incoming connections. By default, xymonproxy listens on all IP-addresses assigned to the host. If no portnumber is given, port 1984 will be used.

--timeout=N

Specifies the number of seconds after which a connection is aborted due to a timeout. Default: 10 seconds.

--report=[PROXYHOSTNAME.]SERVICE

If given, this option causes xymonproxy to send a status report every 5 minutes to the Xymon server about itself. If you have set the standard Xymon environment, you can use "--report=xymonproxy" to have xymonproxy report its status to a "xymonproxy" column in Xymon. The default for PROXYHOSTNAME is the $MACHINE environment variable, i.e. the hostname of the server running xymonproxy. See REPORT OUTPUT below for an explanation of the report contents.

--lqueue=N

Size of the listen-queue where incoming connections can queue up before being processed. This should be large to accommodate bursts of activity from clients. Default: 512.

--daemon

Run in daemon mode, i.e. detach and run as a background process. This is the default.

--no-daemon

Runs xymonproxy as a foreground process.

--pidfile=FILENAME

Specifies the location of a file containing the process-ID of the xymonproxy daemon process. Default: /var/run/xymonproxy.pid.

--logfile=FILENAME

Sends all logging output to the specified file instead of stderr.

--log-details

Log details (IP-address, message type and hostname) to the logfile. This can also be enabled and disabled at run-time by sending the xymonproxy process a SIGUSR1 signal.

--debug

Enable debugging output.

## REPORT OUTPUT
If enabled via the "--report" option, xymonproxy will send a status message about itself to the Xymon server once every 5 minutes.

The status message includes the following information:

Incoming messages

The total number of connections accepted from clients since the proxy started. The "(N msgs/second)" is the average number of messages per second over the past 5 minutes.

Outbound messages

The total number of messages sent to the Xymon server. Note that this is probably smaller than the number of incoming messages, since xymonproxy merges messages before sending them.

Incoming - Combo messages

The number of "combo" messages received from a client.

Incoming - Status messages

The number of "status" messages received from a client. xymonproxy attempts to merge these into "combo" messages. The "Messages merged" is the number of "status" messages that were merged into a combo message, the "Resulting combos" is the number of "combo" messages that resulted from the merging.

Incoming - Other messages

The number of other messages (data, notes, ack, query, ...) messages received from a client.

Proxy resources - Connection table size

This is the number of connection table slots in the proxy. This measures the number of simultaneously active requests that the proxy has handled, and so gives an idea about the peak number of clients that the proxy has handled simultaneously.

Proxy resources - Buffer space

This is the number of KB memory allocated for network buffers.

Timeout details - reading from client

The number of messages dropped because reading the message from the client timed out.

Timeout details - connecting to server

The number of messages dropped, because a connection to the Xymon server could not be established.

Timeout details - sending to server

The number of messages dropped because the communication to the Xymon server timed out after a connection was established.

Timeout details - recovered

When a timeout happens while sending the status message to the server, xymonproxy will attempt to recover the message and retry sending it to the server after waiting a few seconds. This number is the number of messages that were recovered, and so were not lost.

Timeout details - reading from server

The number of response messages that timed out while attempting to read them from the server. Note that this applies to the "config" and "query" messages only, since all other message types do not get any response from the servers.

Timeout details - sending to client

The number of response messages that timed out while attempting to send them to the client. Note that this applies to the "config" and "query" messages only, since all other message types do not get any response from the servers.

Average queue time

The average time it took the proxy to process a message, calculated from the messages that have passed through the proxy during the past 5 minutes. This number is computed from the messages that actually end up establishing a connection to the Xymon server, i.e. status messages that were combined into combo-messages do not go into the calculation - if they did, it would reduce the average time, since it is faster to merge messages than send them out over the network.

##
If you think the numbers do not add up, here is how they relate.

The "Incoming messages" should be equal to the sum of the "Incoming Combo/Status/Page/Other messages", or slightly more because messages in transit are not included in the per-type message counts.

The "Outbound messages" should be equal to sum of the "Incoming Combo/Page/Other messages", plus the "Resulting combos" count, plus "Incoming Status messages" minus "Messages merged" (this latter number is the number of status messages that were NOT merged into combos, but sent directly). The "Outbound messages" may be slightly lower than that, because messages in transit are not included in the "Outbound messages" count until they have been fully sent.

## SIGNALS
SIGHUP

Re-opens the logfile, e.g. after it has been rotated.

SIGTERM

Shut down the proxy.

SIGUSR1

Toggles logging of individual messages.

## SEE ALSO
xymon(1), xymond(1), xymon(7)


yate

package: yate

title: yate(8)

summary: launch the YATE telephony engine

text:
# yate(8)

## NAME
yate - launch the YATE telephony engine

## SYNOPSIS
yate [options] [commands]

## DESCRIPTION
yate is a telephony engine that supports client, PBX and IVR functions trough plugins.

## OPTIONS

### General
-h, --help

Display a short help message and exit

-V, --version

Display program version and exit

-v

Verbose logging (you can use more than once)

-q

Quieter logging (you can use more than once)

-d

Daemonify, suppress output unless logged

-s[=msec]

Supervised, restart if crashes or locks up, optionally sleeps initially

-r

Enable rotation of log file (needs -s and -l)

-l filename

Log to file - should be used whenever running in daemon mode

-p filename

Write PID of the supervisor or primary thread to file

-n configname

Use specified configuration name, overrides default "yate"

-c pathname

Path to conf files directory, overrides compiled-in value

-u pathname

Path to user data files directory, overrides compiled-in value

-m pathname

Path to modules directory, overrides compiled-in value

-e pathname

Path to shared directory, overrides compiled-in value

-x dirpath

Absolute or relative path to extra modules directory (can be repeated)

-w directory

Change working directory

-N nodename

Set the name of the node in a cluster

### Debugging options (may not be compiled in)
-C

Enable core dumps if supported by the operating system

-F

Increase the maximum file handle to compiled value

-S

Set size of supervised sanity points pool

-t

Truncate the log file instead of appending to it

-D[options]

Special debugging options

-Da

Abort (coredumps if allowed) if bugs are encountered

-Dm

Attempt to debug mutex deadlocks by setting a maximum 10s limit, if repeated halves the limit

-Dd

Enable some locking debugging and safety features, degrades performance

-Dl

Attempt to load modules without having their symbols globally visible

-Dc

Call dlclose() until it gets an error

-Du

Do not unload modules, just try to call thier finalization code

-Di

Reinitialize after first initialization

-Dx

Exit immediately after initialization

-Dw

Delay for one second the creation of the first worker thread

-Do

Colorize the output using ANSI control character sequences

-Ds

Abort if bugs are encountered even during shutdown

-DO

Attempt to debug all object allocations by counting objects per plugin, degrades performance

-Dn

Do not add timestamps to debugging messages

-Dt

Add start time relative timestamps to debugging messages

-De

Add EPOCH (1-1-1970 GMT) based timestamps to debugging messages

-Df

Add GMT timestamps to debugging messages in format YYYYMMDDhhmmss.uuuuuu

-DF

Add GMT timestamps to debugging messages in format YYYY-MM-DD_hh:mm:ss.uuuuuu

-Dz

Add local timezone timestamps to debugging messages in format YYYYMMDDhhmmss.uuuuuu

-DZ

Add local timezone timestamps to debugging messages in format YYYY-MM-DD_hh:mm:ss.uuuuuu

## COMMANDS
Each command is sent to the YATE modules immediately after initialization. Modules define command syntax so that is not described here. Please look at the documentation for each module.

## SIGNALS
- SIGTERM and SIGINT (Ctrl-C) will cleanly stop the engine

- SIGQUIT (Ctrl-\) will reinitialize the modules

- SIGHUP will reinitialize the modules if started in daemon mode (-d)

- SIGUSR1 will initiate a gracefull restart (when no plugin is busy)

- SIGUSR2 will initiate an immediate restart

## BUGS
Under various *BSD implementations the dlclose() function is broken and may generate a segfault on exit.

Some libpthread implementations are broken and may fail to start the threads or fail to cleanup when the thread terminates.

## AUTHORS
Paul Chitescu <paulc@voip.null.ro>

Diana Cionoiu <diana@voip.null.ro>

## SEE ALSO
yate-config(8)


yate-config

package: yate-devel

title: yate-config(8)

text:
# yate-config(8)

## NAME
yate-config - retrieve metainformation about the YATE telephony engine

## SYNOPSIS
yate-config [options]

## DESCRIPTION
The yate-config program is used to retrieve information about the installed YATE engine. It is typically used to compile and link modules against the engine's library.

Here is a typical usage scenario in a Makefile:

module.yate: module.cpp

g++ `yate-config --c-all --ldflags` module.cpp `yate-config --libs`

## OPTIONS

### Version and paths
--version

Reports the installed YATE version (in x.y.z format)

--release

Reports the installed YATE code status (if not release) and release number

--config

Returns the configuration files directory

--modules

Returns the modules directory

--share

Returns the base shared directory

--scripts

Returns the scripts directory

--skins

Returns the base skins directory

### Compiler flags
--cflags

Various C++ compiler flags

--includes

Include option and path to the header files

--c-all

All compiler options - the above two concatenated

### Linker flags
--ldflags

Various linker flags

--libs

Library option and libraries names

--ld-all

All linker options - the above two concatenated

## AUTHORS
Paul Chitescu <paulc@voip.null.ro>

Diana Cionoiu <diana@voip.null.ro>

## SEE ALSO
yate(8), pkg-config(1)


yaz-ztest

package: yaz

title: yaz-ztest(8)

summary: Z39.50/SRU Test Server

text:
# yaz-ztest(8)

## NAME
yaz-ztest - Z39.50/SRU Test Server

## SYNOPSIS
application [-install] [-installa] [-remove] [-a file] [-v level] [-l file] [-u uid] [-c config] [-f vconfig] [-C fname] [-t minutes] [-k kilobytes] [-K] [-d daemon] [-w dir] [-p pidfile] [-r kilobytes] [-ziDSTV1] [listener-spec...]

## DESCRIPTION
yaz-ztest is a Z39.50/SRU test server that uses the YAZ generic frontend server (GFS) API. The server acts as a real Z39.50/SRU server but does not use a database. It returns a random hit count and returns a subset of a few built-in records.

The listener-spec consists of a transport mode followed by a colon, followed by a listener address. The transport mode is either tcp, unix, or ssl.

For TCP and SSL, an address has the form:

```
    hostname | IP-number [ : portnumber ]

```

For UNIX local socket, the address is the filename of the local socket.

## OPTIONS
-a file

Specify a file for dumping PDUs (for diagnostic purposes). The special name - (dash) sends output to stderr.

-S

Don't fork or make threads on connection requests. This is good for debugging, but not recommended for real operation: Although the server is asynchronous and non-blocking, it can be nice to keep a software malfunction (okay then, a crash) from affecting all current users.

-1

Like -S but after one session the server exits. This mode is for debugging only.

-T

Operate the server in threaded mode. The server creates a thread for each connection rather than fork a process. Only available on UNIX systems that offer POSIX threads.

-s

Use the SR protocol (obsolete).

-z

Use the Z39.50 protocol (default). This option and -s complement each other. You can use both multiple times on the same command line, between listener-specifications (see below). This way, you can set up the server to listen for connections in both protocols concurrently, on different local ports.

-l file

The logfile.

-c config

A user option that serves as a specifier for some sort of configuration, usually a filename. The argument to this option is transferred to member configname of the statserv_options_block.

-f vconfig

This specifies an XML file that describes one or more YAZ frontend virtual servers.

-C fname

Sets SSL certificate file name for server (PEM).

-v level

The log level. Use a comma-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}.

-u uid

Set user ID. Sets the real UID of the server process to that of the given user. It's useful if you aren't comfortable with having the server run as root, but you need to start it as such to bind a privileged port.

-w dir

The server changes to this directory before listening to incoming connections. This option is useful when the server is operating from the inetd daemon (see -i).

-p pidfile

Specifies that the server should write its Process ID to the file given by pidfile. A typical location would be /var/run/yaz-ztest.pid.

-i

Use this to make the the server run from the inetd server (UNIX only).

-D

Use this to make the server put itself in the background and run as a daemon. If neither -i nor -D is given, the server starts in the foreground.

-install

Use this to install the server as an NT service (Windows NT/2000/XP only). Control the server by going to the Services in the Control Panel.

-installa

Use this to install the server as an NT service and mark it as "auto-start. Control the server by going to the Services in the Control Panel.

-remove

Use this to remove the server from the NT services (Windows NT/2000/XP only).

-t minutes

Idle session timeout, in minutes.

-k size

Maximum record size/message size, in kilobytes.

-K

Forces no-keepalive for HTTP sessions. By default GFS will keep sessions alive for HTTP 1.1 sessions (as defined by the standard). Using this option will force GFS to close the connection for each operation.

-r size

Maximum size of log file before rotation occurs, in kilobytes. Default size is 1048576 k (=1 GB).

-d daemon

Set name of daemon to be used in hosts access file. See hosts_access(5) and tcpd(8).

-m time-format

Sets the format of time-stamps in the log-file. Specify a string in the input format to strftime().

-V

Display YAZ version and exit.

## TESTING
yaz-ztest normally returns a random hit count between 0 and 24. However, if a query term includes leading digits, then the integer value of that term is used as hit count. This allows testers to return any number of hits. yaz-ztest includes 24 MARC records for testing. Hit counts exceeding 24 will make yaz-ztest return the same record batch over and over. So record at position 1, 25, 49, etc. are equivalent.

For XML, if no element set is given or element has value "marcxml", MARCXML is returned (each of the 24 dummy records converted from ISO2709 to XML). For element set OP, then OPAC XML is returned.

yaz-ztest may also return predefined XML records (for testing). This is enabled if YAZ_ZTEST_XML_FETCH environment variable is defined. A record is fetched from a file (one record per file). The path for the filename is FE.d.xml where F is the YAZ_ZTEST_XML_FETCH value (possibly empty), E is element-set, d is record position (starting from 1).

The following databases are honored by yaz-ztest: Default, slow and db.* (all databases with prefix "db"). Any other database will make yaz-ztest return diagnostic 109: "Database unavailable".

Options for search may be included in the form or URL get arguments included as part of the Z39.50 database name. The following database options are present: search-delay, present-delay, fetch-delay and seed.

The former, delay type options, specify a fake delay (sleep) that yaz-ztest will perform when searching, presenting, fetching records respectively. The value of the delay may either be a fixed floating point value which specifies the delay in seconds. Alternatively the value may be given as two floating point numbers separated by colon, which will make yaz-ztest perform a random sleep between the first and second number.

The database parameter seed takes an integer as value. This will call srand with this integer to ensure that the random behavior can be re-played.

Suppose we want searches to take between 0.1 and 0.5 seconds and a fetch to take 0.2 second. To access test database Default we'd use: Default?search-delay=0.1:0.5&fetch-delay=0.2.

## GFS CONFIGURATION AND VIRTUAL HOSTS
The Virtual hosts mechanism allows a YAZ frontend server to support multiple backends. A backend is selected on the basis of the TCP/IP binding (port+listening adddress) and/or the virtual host.

A backend can be configured to execute in a particular working directory. Or the YAZ frontend may perform CQL to RPN conversion, thus allowing traditional Z39.50 backends to be offered as a SRW/SRU service. SRW/SRU Explain information for a particular backend may also be specified.

For the HTTP protocol, the virtual host is specified in the Host header. For the Z39.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1.

Note

Not all Z39.50 clients allow the VHOST information to be set. For those, the selection of the backend must rely on the TCP/IP information alone (port and address).

The YAZ frontend server uses XML to describe the backend configurations. Command-line option -f specifies filename of the XML configuration.

The configuration uses the root element yazgfs. This element includes a list of listen elements, followed by one or more server elements.

The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server. Content for a listener:

CDATA (required)

The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc.

attribute id (optional)

Identifier for this listener. This may be referred to from server sections.

Note

We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers.

The server describes a server and the parameters for this server type. Content for a server:

attribute id (optional)

Identifier for this server. Currently not used for anything, but it might be for logging purposes.

attribute listenref (optional)

Specifies one or more listeners for this server. Each server ID is separated by a comma. If this attribute is not given, the server is accessible from all listeners. In order for the server to be used for real, however, the virtual host must match if specified in the configuration.

element config (optional)

Specifies the server configuration. This is equivalent to the config specified using command line option -c.

element directory (optional)

Specifies a working directory for this backend server. If specified, the YAZ frontend changes current working directory to this directory whenever a backend of this type is started (backend handler bend_start), stopped (backend handler hand_stop) and initialized (bend_init).

element host (optional)

Specifies the virtual host for this server. If this is specified a client must specify this host string in order to use this backend.

element cql2rpn (optional)

Specifies a filename that includes CQL to RPN conversion for this backend server. See ???. If given, the backend server will only "see" a Type-1/RPN query.

element ccl2rpn (optional)

Specifies a filename that includes CCL to RPN conversion for this backend server. See ???. If given, the backend server will only "see" a Type-1/RPN query.

element stylesheet (optional)

Specifies the stylesheet reference to be part of SRU HTTP responses when the client does not specify one. If none is given, then if the client does not specify one, then no stylesheet reference is part of the SRU HTTP response.

element client_query_charset (optional)

If specified, a conversion from the character set given to UTF-8 is performed by the generic frontend server. It is only executed for Z39.50 search requests (SRU/Solr are assumed to be UTF-8 encoded already).

element docpath (optional)

Specifies a path for local file access using HTTP. All URLs with a leading prefix (/ excluded) that matches the value of docpath are used for file access. For example, if the server is to offer access in directory xsl, the docpath would be xsl and all URLs of the form http://host/xsl will result in a local file access.

element explain (optional)

Specifies SRW/SRU ZeeRex content for this server. Copied verbatim to the client. As things are now, some of the Explain content seem redundant because host information, etc. is also stored elsewhere.

element maximumrecordsize (optional)

Specifies maximum record size/message size, in bytes. This value also serves as the maximum size of incoming packages (for Record Updates etc). It's the same value as that given by the -k option.

element retrievalinfo (optional)

Enables the retrieval facility to support conversions and specifications of record formats/types. See ??? for more information.

The XML below configures a server that accepts connections from two ports, TCP/IP port 9900 and a local UNIX file socket. We name the TCP/IP server public and the other server internal.

```

 <yazgfs>

  <listen id="public">tcp:@:9900</listen>

  <listen id="internal">unix:/var/tmp/socket</listen>

  <server id="server1">

    <host>server1.mydomain</host>

    <directory>/var/www/s1</directory>

    <config>config.cfg</config>

  </server>

  <server id="server2" listenref="public,internal">

    <host>server2.mydomain</host>

    <directory>/var/www/s2</directory>

    <config>config.cfg</config>

    <cql2rpn>../etc/pqf.properties</cql2rpn>

    <explain xmlns="http://explain.z3950.org/dtd/2.0/">

      <serverInfo>

        <host>server2.mydomain</host>

        <port>9900</port>

        <database>a</database>

      </serverInfo>

    </explain>

  </server>

  <server id="server3" listenref="internal">

    <directory>/var/www/s3</directory>

    <config>config.cfg</config>

  </server>

 </yazgfs>

```

There are three configured backend servers. The first two servers, "server1" and "server2", can be reached by both listener addresses. "server1" is reached by all (two) since no listenref attribute is specified. "server2" is reached by the two listeners specified. In order to distinguish between the two, a virtual host has been specified for each server in the host elements.

For "server2" elements for CQL to RPN conversion is supported and explain information has been added (a short one here to keep the example small).

The third server, "server3" can only be reached via listener "internal".

## FILES
yaz-<version>/ztest/yaz-ztest.c

yaz-<version>/include/yaz/backend.h

## SEE ALSO
yaz(7) yaz-log(7)

## AUTHORS
Index Data


package: zabbix-agent

title: zabbix_agentd(8)

summary: Zabbix agent daemon

text:
# zabbix_agentd(8)

## NAME
zabbix_agentd - Zabbix agent daemon

## SYNOPSIS
zabbix_agentd [-c config-file]

zabbix_agentd [-c config-file] -p

zabbix_agentd [-c config-file] -t item-key

zabbix_agentd [-c config-file] -R runtime-option

zabbix_agentd [-c config-file] -T

zabbix_agentd -h

zabbix_agentd -V

## DESCRIPTION
zabbix_agentd is a daemon for monitoring various server parameters.

## OPTIONS
-c, --config config-file

Use the alternate config-file instead of the default one.

-f, --foreground

Run Zabbix agent in foreground.

-R, --runtime-control runtime-option

Perform administrative functions according to runtime-option.

Runtime control options userparameter_reload

Reload user parameters from the configuration file

log_level_increase[=target]

Increase log level, affects all processes if target is not specified

log_level_decrease[=target]

Decrease log level, affects all processes if target is not specified

Log level control targets process-type

All processes of specified type (active checks, collector, listener)

process-type,N

Process type and number (e.g., listener,3)

pid

Process identifier, up to 65535. For larger values specify target as "process-type,N"

-p, --print

Print known items and exit. For each item either generic defaults are used, or specific defaults for testing are supplied. These defaults are listed in square brackets as item key parameters. Returned values are enclosed in square brackets and prefixed with the type of the returned value, separated by a pipe character. For user parameters type is always t, as the agent can not determine all possible return values. Items, displayed as working, are not guaranteed to work from the Zabbix server or zabbix_get when querying a running agent daemon as permissions or environment may be different. Returned value types are:

d

Number with a decimal part.

m

Not supported. This could be caused by querying an item that only works in the active mode like a log monitoring item or an item that requires multiple collected values. Permission issues or incorrect user parameters could also result in the not supported state.

s

Text. Maximum length not limited.

t

Text. Same as s.

u

Unsigned integer.

-t, --test item-key

Test single item and exit. See --print for output description.

-T, --test-config

Validate configuration file and exit.

-h, --help

Display this help and exit.

-V, --version

Output version information and exit.

## FILES
/usr/local/etc/zabbix_agentd.conf

Default location of Zabbix agent configuration file (if not modified during compile time).

## SEE ALSO
Documentation

zabbix_get(1), zabbix_proxy(8), zabbix_sender(1), zabbix_server(8), zabbix_js(1), zabbix_agent2(8), zabbix_web_service(8)


title: zabbix_agent2(8)

summary: Zabbix agent 2

text:
# zabbix_agent2(8)

## NAME
zabbix_agent2 - Zabbix agent 2

## SYNOPSIS
zabbix_agent2 [-c config-file]

zabbix_agent2 [-c config-file] [-v] -p

zabbix_agent2 [-c config-file] [-v] -t item-key

zabbix_agent2 [-c config-file] -R runtime-option

zabbix_agent2 [-c config-file] -T

zabbix_agent2 -h

zabbix_agent2 -V

## DESCRIPTION
zabbix_agent2 is an application for monitoring parameters of various services.

## OPTIONS
-c, --config config-file

Use the alternate config-file instead of the default one.

-R, --runtime-control runtime-option

Perform administrative functions according to runtime-option.

Runtime control options userparameter_reload

Reload user parameters from the configuration file

log_level_increase

Increase log level

log_level_decrease

Decrease log level

help

List available runtime control options

metrics

List available metrics

version

Display version

-p, --print

Print known items and exit. For each item either generic defaults are used, or specific defaults for testing are supplied. These defaults are listed in square brackets as item key parameters. Returned values are enclosed in square brackets and prefixed with the type of the returned value, separated by a pipe character. For user parameters type is always t, as the agent can not determine all possible return values. Items, displayed as working, are not guaranteed to work from the Zabbix server or zabbix_get when querying a running agent daemon as permissions or environment may be different. Returned value types are:

d

Number with a decimal part.

m

Not supported. This could be caused by querying an item that only works in the active mode like a log monitoring item or an item that requires multiple collected values. Permission issues or incorrect user parameters could also result in the not supported state.

s

Text. Maximum length not limited.

t

Text. Same as s.

u

Unsigned integer.

-t, --test item-key

Test single item and exit. See --print for output description.

-v, --verbose

Enable verbose output when test item or print known items.

-T, --test-config

Validate configuration file and exit.

-h, --help

Display this help and exit.

-V, --version

Output version information and exit.

## FILES
/usr/local/etc/zabbix_agent2.conf

Default location of Zabbix agent 2 configuration file (if not modified during compile time).

## SEE ALSO
Documentation

zabbix_agentd(8), zabbix_get(1), zabbix_proxy(8), zabbix_sender(1), zabbix_server(8), zabbix_js(1), zabbix_web_service(8)


package: zabbix-proxy-common

title: zabbix_proxy(8)

summary: Zabbix proxy daemon

text:
# zabbix_proxy(8)

## NAME
zabbix_proxy - Zabbix proxy daemon

## SYNOPSIS
zabbix_proxy [-c config-file]

zabbix_proxy [-c config-file] -R runtime-option

zabbix_proxy [-c config-file] -T

zabbix_proxy -h

zabbix_proxy -V

## DESCRIPTION
zabbix_proxy is a daemon that collects monitoring data from devices and sends it to Zabbix server.

## OPTIONS
-c, --config config-file

Use the alternate config-file instead of the default one.

-f, --foreground

Run Zabbix proxy in foreground.

-R, --runtime-control runtime-option

Perform administrative functions according to runtime-option.

Runtime control options config_cache_reload

Reload configuration cache. Ignored if cache is being currently loaded. Active Zabbix proxy will connect to the Zabbix server and request configuration data. Default configuration file (unless -c option is specified) will be used to find PID file and signal will be sent to process, listed in PID file.

snmp_cache_reload

Reload SNMP cache.

housekeeper_execute

Execute the housekeeper. Ignored if housekeeper is being currently executed.

diaginfo[=section]

Log internal diagnostic information of the specified section. Section can be historycache, preprocessing, locks. By default diagnostic information of all sections is logged.

prof_enable[=target]

Enable profiling, affects all processes if target is not specified

prof_disable[=target]

Disable profiling, affects all processes if target is not specified

log_level_increase[=target]

Increase log level, affects all processes if target is not specified.

log_level_decrease[=target]

Decrease log level, affects all processes if target is not specified.

Log level control targets process-type

All processes of specified type (availability manager, browser poller, configuration syncer, data sender, discovery manager, discovery worker, history syncer, housekeeper, http poller, icmp pinger, internal poller, ipmi manager, ipmi poller, java poller, odbc poller, poller, agent poller, http agent poller, snmp poller, preprocessing manager, preprocessing worker, self-monitoring, snmp trapper, task manager, trapper, unreachable poller, vmware collector)

process-type,N

Process type and number (e.g., poller,3)

pid

Process identifier

Profiling control targets process-type

All processes of specified type (availability manager, browser poller, configuration syncer, data sender, discovery manager, discovery worker, history syncer, housekeeper, http poller, icmp pinger, internal poller, ipmi manager, ipmi poller, java poller, odbc poller, poller, agent poller, http agent poller, snmp poller, preprocessing manager, preprocessing worker, self-monitoring, snmp trapper, task manager, trapper, unreachable poller, vmware collector)

process-type,N

Process type and number (e.g., history syncer,1)

pid

Process identifier

scope

(rwlock, mutex, processing) can be used with process-type (e.g., history syncer,1,processing)

-T, --test-config

Validate configuration file and exit.

-h, --help

Display this help and exit.

-V, --version

Output version information and exit.

## FILES
/usr/local/etc/zabbix_proxy.conf

Default location of Zabbix proxy configuration file (if not modified during compile time).

## SEE ALSO
Documentation

zabbix_agentd(8), zabbix_get(1), zabbix_sender(1), zabbix_server(8), zabbix_js(1), zabbix_agent2(8), zabbix_web_service(8)


package: zabbix-web-service

title: zabbix_web_service(8)

summary: Zabbix web service

text:
# zabbix_web_service(8)

## NAME
zabbix_web_service - Zabbix web service

## SYNOPSIS
zabbix_web_service [-c config-file]

zabbix_web_service [-c config-file] -T

zabbix_web_service -h

zabbix_web_service -V

## DESCRIPTION
zabbix_web_service is an application for providing web services to Zabbix components.

## OPTIONS
-c, --config config-file

Use the alternate config-file instead of the default one.

-T, --test-config

Validate configuration file and exit.

-h, --help

Display this help and exit.

-V, --version

Output version information and exit.

## FILES
/usr/local/etc/zabbix_web_service.conf

Default location of Zabbix web service configuration file (if not modified during compile time).

## SEE ALSO
Documentation

zabbix_agentd(8), zabbix_get(1), zabbix_proxy(8), zabbix_sender(1), zabbix_server(8), zabbix_js(1), zabbix_agent2(8)


zerofree

package: zerofree

title: zerofree(8)

text:
# zerofree(8)

## NAME
zerofree — zero free blocks from ext2/3 file-systems

## SYNOPSIS
zerofree [-n] [-v] filesystem

## DESCRIPTION
zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3 filesystem (e.g. /dev/hda1) and fills them with zeroes. This is useful if the device on which this file-system resides is a disk image. In this case, depending on the type of disk image, a secondary utility may be able to reduce the size of the disk image after zerofree has been run.

The usual way to achieve the same result (zeroing the unallocated blocks) is to run dd (1) to create a file full of zeroes that takes up the entire free space on the drive, and then delete this file. This has many disadvantages, which zerofree alleviates:

•

it is slow;

•

it makes the disk image (temporarily) grow to its maximal extent;

•

it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

filesystem has to be unmounted or mounted read-only for zerofree to work. It will exit with an error message if the filesystem is mounted writable. To remount the root file-system readonly, you can first switch to single user runlevel (telinit 1) then use mount -o remount,ro filesystem.

zerofree has been written to be run from GNU/Linux systems installed as guest OSes inside a virtual machine. It may however be useful in other situations.

## OPTIONS
-n

Perform a dry run (do not modify the file-system);

-v

Be verbose.

## SEE ALSO
dd (1).

## AUTHOR
This manual page was written by Thibaut Paumard <paumard@users.sourceforge.net> for the Debian system (but may be used by others). Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation.

On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-2.


fsck.zfs

package: zfs-utils

title: fsck.zfs(8)

summary: dummy ZFS filesystem checker

text:
# fsck.zfs(8)

## NAME
fsck.zfs — dummy ZFS filesystem checker

## SYNOPSIS
fsck.zfs

[options] dataset…

## DESCRIPTION
fsck.zfs is a thin shell wrapper that at most checks the status of a dataset's container pool. It is installed by OpenZFS because some Linux distributions expect a fsck helper for all filesystems.

If more than one dataset is specified, each is checked in turn and the results binary-ored.

## OPTIONS
Ignored.

## NOTES
ZFS datasets are checked by running zpool scrub on the containing pool. An individual ZFS dataset is never checked independently of its pool, which is unlike a regular filesystem.

However, the fsck(8) interface still allows it to communicate some errors: if the dataset is in a degraded pool, then fsck.zfs will return exit code 4 to indicate an uncorrected filesystem error.

Similarly, if the dataset is in a faulted pool and has a legacy /etc/fstab record, then fsck.zfs will return exit code 8 to indicate a fatal operational error.

## SEE ALSO
fstab(5), fsck(8), zpool-scrub(8)


mount.zfs

title: mount.zfs(8)

summary: mount ZFS filesystem

text:
# mount.zfs(8)

## NAME
mount.zfs — mount ZFS filesystem

## SYNOPSIS
mount.zfs

[-sfnvh] [-o options] dataset mountpoint

## DESCRIPTION
The mount.zfs helper is used by mount(8) to mount filesystem snapshots and mountpoint=legacy ZFS filesystems, as well as by zfs(8) when the ZFS_MOUNT_HELPER environment variable is not set. Users should should invoke either mount(8) or zfs(8) in most cases.

options are handled according to the Temporary Mount Point Properties section in zfsprops(7), except for those described below.

If /etc/mtab is a regular file and -n was not specified, it will be updated via libmount.

## OPTIONS
-s

Ignore unknown (sloppy) mount options.

-f

Do everything except actually executing the system call.

-n

Never update /etc/mtab.

-v

Print resolved mount options and parser state.

-h

Print the usage message.

-o zfsutil

This private flag indicates that mount(8) is being called by the zfs(8) command.

## SEE ALSO
fstab(5), mount(8), zfs-mount(8)