This patch introduces two new commands for cache management:
[rrdtool.git] / doc / rrdcached.pod
index bdb8949..b01165e 100644 (file)
@@ -6,7 +6,7 @@ rrdcached - Data caching daemon for rrdtool
 
 =head1 SYNOPSIS
 
-B<rrdcached> [B<-l> I<address>] [B<-w> I<timeout>] [B<-z> I<delay>] [B<-f> I<timeout>] [B<-j> I<dir>]
+B<rrdcached> [B<-l/-L> I<address>] [B<-w> I<timeout>] [B<-z> I<delay>] [B<-f> I<timeout>] [B<-j> I<dir>] [-F] [B<-b> I<dir> [B<-B>]]
 
 =head1 DESCRIPTION
 
@@ -35,18 +35,28 @@ interpreted as the path to a UNIX domain socket. Otherwise the address or node
 name are resolved using L<getaddrinfo>.
 
 For network sockets, a port may be specified by using the form
-I<address>:I<port>.  The default port is 42217.
+C<B<[>I<address>B<]:>I<port>>. If the address is an IPv4 address or a fully
+qualified domain name (i.E<nbsp>e. the address contains at least one dot
+(C<.>)), the square brackets can be omitted, resulting in the (simpler)
+C<I<address>B<:>I<port>> pattern.. The default port is B<42217/udp>.
 
-These formats are accepted:
+The following formats are accepted. Please note that the address of the UNIX
+domain socket B<must> start with a slash in the second case!
 
    unix:</path/to/unix.sock>
-   </path/to/unix.sock>
+   /<path/to/unix.sock>
    <hostname-or-ip>
-   <hostname-or-ip>:<port>
+   [<hostname-or-ip>]:<port>
+   <hostname-or-ipv4>:<port>
 
 If the B<-l> option is not specified the default address,
 C<unix:/tmp/rrdcached.sock>, will be used.
 
+=item B<-L> I<address>
+
+Same as B<-l>, except creates a low-privilege socket.  See B<SECURITY
+CONSIDERATIONS> for more information.
+
 =item B<-w> I<timeout>
 
 Data is written to disk every I<timeout> seconds. If this option is not
@@ -82,7 +92,20 @@ found, all updates therein will be read into memory before the daemon
 starts accepting new connections.
 
 The journal will be rotated with the same frequency as the flush timer
-given by B<-f>.  On clean shutdown, the journal files are removed.
+given by B<-f>.
+
+When journaling is enabled, the daemon will use a fast shutdown procedure.
+Rather than flushing all files to disk, it will make sure the journal is
+properly written and exit immediately.  Although the RRD data files are
+not fully up-to-date, no information is lost; all pending updates will be
+replayed from the journal next time the daemon starts up.
+
+To disable fast shutdown, use the B<-F> option.
+
+=item B<-F>
+
+ALWAYS flush all updates to the RRD data files when the daemon is shut
+down, regardless of journal setting.
 
 =item B<-b> I<dir>
 
@@ -102,9 +125,15 @@ used.
   updated by the daemon,  assuming the base directory
   "/tmp".
 
+=item B<-B>
+
+Only permit writes into the base directory specified in B<-b> (and any
+sub-directories).  This does B<NOT> detect symbolic links.  Paths
+containing C<../> will also be blocked.
+
 =back
 
-=head1 EFFECTED RRDTOOL COMMANDS
+=head1 AFFECTED RRDTOOL COMMANDS
 
 The following commands may be made aware of the B<rrdcached> using the command
 line argument B<--daemon> or the environment variable B<RRDCACHED_ADDRESS>:
@@ -182,9 +211,8 @@ The downside of caching values is that they won't show up in graphs generated
 from the RRDE<nbsp>files. To get around this, the daemon provides the "flush
 command" to flush specific files. This means that the file is inserted at the
 B<head> of the update queue or moved there if it is already enqueued. The flush
-command will return after the update thread has dequeued the file, so there is
-a good chance that the file has been updated by the time the client receives
-the response from the daemon, but there is no guarantee.
+command will return only after the file's pending updates have been written
+to disk.
 
  +------+   +------+                               +------+
  ! head !   ! root !                               ! tail !
@@ -197,7 +225,8 @@ the response from the daemon, but there is no guarantee.
  +---+----+---+    +------+-----+             +---+----+---+
  ! File:  foo !    ! File:  bar !             ! File:  qux !
  ! First: 101 !    ! First: 119 !             ! First: 180 !
- ! Next:   ---+--->! Next:   ---+---> ... --->! Next:   -  !
+ ! Next:&bar -+--->! Next:&... -+---> ... --->! Next:NULL  !
+ | Prev:NULL  !<---+-Prev:&foo  !<--- ... ----+-Prev: &... !
  +============+    +============+             +============+
  ! Time:  100 !    ! Time:  120 !             ! Time:  180 !
  ! Value:  10 !    ! Value: 0.1 !             ! Value: 2,2 !
@@ -243,15 +272,32 @@ ASCII art rocks.
 
 =head1 SECURITY CONSIDERATIONS
 
-This daemon is meant to improve IOE<nbsp>performance for setups with thousands
-of RRDE<nbsp>file to be updated. So security measures built into the daemon can
-be summarized easily: B<There is no security built in!>
+The client/server protocol does not have any authentication or
+authorization mechanism.  Therefore, take care to restrict which users can
+connect to the daemon.
+
+Control sockets are divided into high-privilege (B<-l>) and low-privilege
+(B<-L>) sockets.  High-privilege sockets accept all commands, whereas
+low-privilege sockets accept only B<FLUSH>, B<STATS>, and B<HELP>.
+
+For a multi-user environment where only certain users require read/write
+access, the recommended configuration uses two sockets as follows:
 
-There is no authentication and authorization, so B<you> will have to take care
-that only authorized clients can talk to the daemon. Since we assume that graph
-collection is done on a dedicated machine, i.E<nbsp>e. the box doesn't do
-anything else and especially does not have any interactive logins other than
-root, a UNIX domain socket should take care of that.
+=over
+
+=item B<-l> I</protected/dir/rrd.sock>
+
+Create a high-privilege unix-domain socket.  This should be protected with
+the same Unix permissions that are used to protect the RRD files.  Updates
+should be directed to this socket.
+
+=item B<-L> I<127.0.0.1>
+
+Create a low-privilege TCP socket listening on localhost.  All users on
+the local system may use this to trigger FLUSH of individual files.  Users
+with read-only access should be directed to this socket.
+
+=back
 
 If you (want to) use the network capability, i.E<nbsp>e. let the daemon bind to
 an IPv4 or IPv6 socket, it is B<your> job to install a packet filter or similar
@@ -312,6 +358,20 @@ Causes the daemon to put I<filename> to the B<head> of the update queue
 (possibly moving it there if the node is already enqueued). The answer will be
 sent B<after> the node has been dequeued.
 
+=item B<FLUSHALL>
+
+Causes the daemon to start flushing ALL pending values to disk.  This
+returns immediately, even though the writes may take a long time.
+
+=item B<PENDING> I<filename>
+
+Shows any "pending" updates for a file, in order.  The updates shown have
+not yet been written to the underlying RRD file.
+
+=item B<FORGET> I<filename>
+
+Removes I<filename> from the cache.  Any pending updates B<WILL BE LOST>.
+
 =item B<HELP> [I<command>]
 
 Returns a short usage message. If no command is given, or I<command> is
@@ -356,6 +416,32 @@ written out to disk.  It is used during journal replay to determine which
 updates have already been applied.  It is I<only> valid in the journal; it
 is not accepted from the other command channels.
 
+=item B<BATCH>
+
+This command initiates the bulk load of multiple commands.  This is
+designed for installations with extremely high update rates, since it
+permits more than one command to be issued per read() and write().
+
+All commands are executed just as they would be if given individually,
+except for output to the user.  Messages indicating success are
+suppressed, and error messages are delayed until the client is finished.
+
+Command processing is finished when the client sends a dot (".") on its
+own line.  After the client has finished, the server responds with an
+error count and the list of error messages (if any).  Each error messages
+indicates the number of the command to which it corresponds, and the error
+message itself.  The first user command after B<BATCH> is command number one.
+
+    client:  BATCH
+    server:  0 Go ahead.  End with dot '.' on its own line.
+    client:  UPDATE x.rrd N:1:2:3            <--- command #1
+    client:  UPDATE y.rrd N:3:4:5            <--- command #2
+    client:  and so on...
+    client:  .
+    server:  2 Errors
+    server:  1 message for command 1
+    server:  12 message for command 12
+
 =back
 
 =head2 Performance Values
@@ -406,6 +492,29 @@ Number of times the journal has been rotated since startup.
 
 =back
 
+=head1 SIGNALS
+
+=over 4
+
+=item SIGINT and SIGTERM
+
+The daemon exits normally on receipt of either of these signals.  Pending
+updates are handled in accordance with the B<-j> and B<-F> options.
+
+=item SIGUSR1
+
+The daemon exits AFTER flushing all updates out to disk.  This may take a
+while.
+
+=item SIGUSR2
+
+The daemon exits immediately, without flushing updates out to disk.
+Pending updates will be replayed from the journal when the daemon starts
+up again.  B<WARNING: if journaling (-j) is NOT enabled, any pending
+updates WILL BE LOST>.
+
+=back
+
 =head1 BUGS
 
 No known bugs at the moment.