collectd is a daemon that receives system statistics and makes them available
in a number of ways. The main daemon itself doesn't have any real functionality
-appart from loading, querying and submitting to plugins. For a description of
+apart from loading, querying and submitting to plugins. For a description of
available plugins please see L</PLUGINS> below.
=head1 OPTIONS
change B<collectd>'s behavior. The path may be relative to the current working
directory.
+=item B<-t>
+
+Test the configuration only. The program immediately exits after parsing the
+config file. A return code not equal to zero indicates an error.
+
=item B<-P> I<E<lt>pid-fileE<gt>>
Specify an alternative pid file. This overwrites any settings in the config
Don't fork to the background. I<collectd> will also B<not> close standard file
descriptors, detach from the session nor write a pid file. This is mainly
-thought for 'supervisioning' init replacements such as I<runit>.
+thought for 'supervising' init replacements such as I<runit>.
=item B<-h>
=head1 PLUGINS
-As noted above, the real power of collectd lies within it's plugins. There are
-two big groups of plugins, B<input> and B<output> plugins:
+As noted above, the real power of collectd lies within it's plugins. A
+(hopefully complete) list of plugins and short descriptions can be found in the
+F<README> file that is distributed with the sourcecode. If you're using a
+package it's a good bet to search somewhere near F</usr/share/doc/collectd>.
+
+There are two big groups of plugins, B<input> and B<output> plugins:
=over 4
=item
-Input plugins are queried periodically. They somehow aquire the current value
+Input plugins are queried periodically. They somehow acquire the current value
of whatever they where designed to work with and submit these values back to
the daemon, i. e. they "dispatch" the values. As an example, the C<cpu plugin>
reads the current cpu-counters of time spent in the various modes (user,
C<network plugin>, for example, is able to send (i.E<nbsp>e. "write") B<and>
receive (i.E<nbsp>e. "dispatch") values. Also, it opens a socket upon
initialization and dispatches the values when it receives them and isn't
-triggered at the same time the input plugins are being read. You can think if
+triggered at the same time the input plugins are being read. You can think of
the network receive part as working asynchronous if it helps.
In addition to the above, there are "logging plugins". Right now those are the
Please note that some plugins, that provide other means of communicating with
the daemon, have manpages of their own to describe their functionality in more
detail. In particular those are L<collectd-email(5)>, L<collectd-exec(5)>,
-L<collectd-perl(5)>, and L<collectd-unixsock(5)>
+L<collectd-perl(5)>, L<collectd-snmp(5)>, and L<collectd-unixsock(5)>
=head1 SEE ALSO
L<collectd-email(5)>,
L<collectd-exec(5)>,
L<collectd-perl(5)>,
+L<collectd-snmp(5)>,
L<collectd-unixsock(5)>,
L<http://collectd.org/>