Re: RRDTOOL 1.4.4 fetch with RRDCACHED_ADDRESS
Florian Forster <[email protected]>
| Newsgroups | gmane.comp.db.rrdtool.devel,gmane.comp.db.rrdtool.user |
|---|---|
| Message-ID | <[email protected]> |
Hi swami, On Thu, Nov 18, 2010 at 05:13:07PM -0800, swami wrote: > 2) create rrd > /usr/local/third-party/rrd/bin/rrdtool create /var/stats/rrd_data/remote_peer_data/rp4.rrd -s 3\ this doesn't work with the current SVN version of RRDtool: Because CREATE is issued via the daemon as well, absolute paths are not allowed for network sockets. Use a UNIX domain socket if you need absolute paths. > 3) update some values > /usr/local/third-party/rrd/bin/rrdtool update remote_peer_data/rp4.rrd N:10 > 4) telnet localhost 42217 > PENDING rp4.rrd This is odd: It should read: PENDING remote_peer_data/rp4.rrd > 4) fetch now > /usr/local/third-party/rrd/bin/rrdtool fetch remote_peer_data/rp4.rrd AVERAGE > ERROR: opening 'remote_peer_data/rp4.rrd': No such file or directory Works fine here. src/rrd_fetch.c hasn't been touched since the daemon code was introduced and the daemon code is basically the same as the other commands, so I doubt the problem is there. You could strace the command to check if there's an error condition that's not reported, but I believe it's more likely a file name was mixed up. Regards, —octo -- Florian octo Forster Hacker in training GnuPG: 0x0C705A15 http://octo.it/ _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
signature.asc
(application/pgp-signature, 835 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJM5jMsAAoJEMPSHpbi2MmgfAUP/AlosHG2m1Pc9F6BtcmvqHN9 SUNgA7W77UGIw317BMSAtabZgeoUsfNGILNYcUMrUwiCEiPzS+cUPZp2deDBTxmS znR63bm7aUhgzid4fIwVj+vJp4qeJXCGRqSk4ws5gJwgjsVPlcckWJ2j4zNFsMfV pHfRYp2g9U8Bb+tHFWgs20JBQm+AWHgwlijqxzff46KAxqSEFoeasqnWbP6JSqtv C51PDZGJOUV3NyzBHBFShOTxoWJ94v1Md39WMGSauKedyXpadlC8YNkJ8koAz1Gy whqrfJ/SdKpA3NMg2SBmtbrPQC7xhoR0jOZjeE+RN3KNqHRdPF7oyjzjEapgEkyu iKfVTjo0SpNiyXsHchviYBooysoM4OW8vZ8/q9ZZMLwUCE2U8qJmDTVI8nYOLeaB RxlQtmxzhPz3BDfDZqMaCRvLrhrjf7y+eJM//SLftpX9ruy97G/6gZvlUwAVEvxc 8gpYcUyfK/6ue8x1XQrovKYCGHyJHBYhYsdDDqAyf4wOUeYJT/YDC6jcZkJ2xjuY G2kKWog5hxwmrCYKEl2DzhFBHPTKKEA0Mr8NAhbRj44tG0pGHEMBq55aeR53/zMB mSNUEkhHFzun9MCzZb69oryXhFytxkhgv9MzObrtf13dkwjg2gMpFqWn5wky6NJv z/6Ounoyz7E8FqmQsgOR =lJhU -----END PGP SIGNATURE-----