[rrd-developers] rrdcached daemonize failed, exiting
kbrint at rufus.net
Wed Sep 24 21:41:43 CEST 2008
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
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
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/
More information about the rrd-developers