[rrd-developers] rrdcached daemonize failed, exiting

[kevin brintnall]

On Wed, Sep 24, 2008 at 08:32:47PM +0200, Tobias Oetiker wrote:
> > I've had to be cautious to refer to files by full path in my testing..  I
> > think this would make things much more DWIM.
> 
> the only snag I can see with this is that if we imagine a
> server that exposes rrdcached over the network for remote update.
> There I think it would be much cleaner if everything was relative
> to the -b root since the update clients do not have to know where
> on the server the rrds are actually stored.
>
> this is different for access via the domain socket where the local
> rrdtool instances have to know where the files are physically and
> so it makes sense when the rrdcached presents an aequivalent view.
> 
> how abou letting the client decide if it wants to present a real
> path or a logical path. Remote clients could then present a logical
> path and local one a real path.

How would the client decide which way to send?  Do we try to differentiate
between local and remote inet sockets?

I think the most common use case is local rrdcached, in which case I think
having the client use realpath() makes the most sense.  That preserves the
user's ability to refer to the file by any relative file name (the
expected result).  Also, it permits us to use the path-based restrictions
I mentioned earlier.

( Also, keep in mind that realpath() will also resolve sym-links and
  ../../etc.  This is important when we consider that the rrdcached data
  structure only keys by strcmp().  If the client makes it absolute that
  is very helpful )

If we have to get into mapping file locations between client and server,
that could get really hairy.  I see five paths that make sense for
exposing rrdcached over a network:

 (1) a client option --base "/my/base" that points to the same location as
     the rrdcached's -b "/server/base".  Matching environment variable
     $RRDCACHED_BASE.

     PRO: allows for arbitrary remapping, relative paths sent to daemon
     CON: need to convert absolute paths to relative

 (2) a client option --relative (and matching $ENV) that instruct the
     client not to make the paths absolute.

     PRO: easy to implement
     CON: client needs to chdir(base directory) for paths to make sense
          both locally and remote

 (3) rrdcached knows about the its clients, and where its base dir is
     mounted on their systems

     PRO: clients continue to realpath() their paths
          - users can address file by any valid path
          - simpler client API
          - resolves any sym-links and relative paths

     CON: how to keep rrdcached up to date?  stop/start to add more
          clients doesn't make sense

 (4) rrdcached-like proxy on the client machine that translates paths?

     PRO: no extra work on client or caching daemon
     CON: another moving part, perhaps unnecessary?

 (5) require same mount point
     CON: obvoius

I see two main install types for rrdcached..  This is what I would target:

(I1) as a local service
     - purpose is largely to ease disk burden
     - cannot expect users to know cached is present
     - optimize for the use cases that work today
       - i.e. refer to file by any valid path

(I2) large collection systems
     - purpose is to distribute polling load
     - users on the polling systems need to handle path discrepancy
       between pollers and storage
        - likely to be common administration
        - we can expect them to do it themselves if we provide the switches
     - users on the rrdcached system work just like "local service" above

What's your thought on how to handle the second kind?  I think we should
make the expected use cases work today for (I1), as long as it doesn't
obviate doing (I2) later.

-- 
 kevin brintnall =~ /kbrint at rufus.net/