Trouble with RRDTool and updated uClibc

[yeager]

I don´t need graph generated by rrdtool, i need only a simple webpage whit this:

................Today.......This week.......This month
wlan...........64MB...........564MB............2354MB
pc1............47MB...........345MB............1005MB
pc2............09MB...........123MB............0547MB
pc3............08MB...........096MB............0802MB

[WlanMan]

Modify the package on your own ?
Seems no one else is interrested in this at the moment.
For my own, i would like to see something like text stats inbuild to the web interface, but at the moment, no interrest to do it .

Greets

[_Denis_]

Hi,
I had some problems with rrdtool and updated uClibc. So what i am done.
1. Prepared my harddrive for extended packages.
2. Update ipkg as said on http://www.nslu2-linux.org/wiki/FAQ/Optware-uClibcBuild
3. Using tutorial on http://wl500g.info/showpost.php?p=18494&postcount=1 install rrdtool
All step done without errors. But when rrtool.sh script try create rrd data file it`s freezed down. I figure out that rrdtool.sh stopped on `rrdtool create "${1}" etc.`.

Anyone can help me with it or recommend some alternative programms for statistics collection?

[oleo]

rrdtool is the only one giving me a trouble. I am looking for a ways to resolve this issue, but it looks like that isnan() function is constantly called in a loop.

I supose there is a bug in rrdtools or some building info or maybe uclibc problem.

I have native compiled libpng, libart_lgpl, freetype, zlib and rrdtool but produced the same resulting lock up.

Strangely
rrdtool create load.rrd DS:sysload:GAUGE:600:U:U RRA:AVERAGE:0.5:1:48
works, while
rrdtool create loadavg.rrd --step 60 DS:load1:GAUGE:120:0:U \
DS:load5:GAUGE:120:0:U DS:load15:GAUGE:120:0:U RRA:AVERAGE:0.5:1:2160
locks up

[_Denis_]

oleo, thanks for reply.

But when call rrdtool with different params, it create a file.

For example.

rrdtool create temperature.rrd --step 300 \
DS:temp:GAUGE:600:-273:5000 \
RRA:AVERAGE:0.5:1:1200 \
RRA:MIN:0.5:12:2400 \
RRA:MAX:0.5:12:2400 \
RRA:AVERAGE:0.5:12:2400

Do you know some similar packages for collect statistic data?

[oleo]

Could you possibly find isolated example that fails. Currently I am creating debug version of rrdtools natively to be debuged on router. And I need minimal example.

[_Denis_]

What do you mean by isolated example?

Work
rrdtool create test.rrd \
DS:inERIVE:600:U:U \
RRA:AVERAGE:0.5:1:600

not work
rrdtool create test1.rrd \
DS:inERIVE:600:0:125000000 \
RRA:AVERAGE:0.5:1:600

May be some problems in min max value?


ps
it doesnt like MIN = 0

[MMCM]

Both commands work for me (WL-500gx, OpenWrt Kamikaze, rrdtool 1.0.50-1).
If prefer rrdtool 1.0 over 1.2 because it's a lot faster generating graphs (2-3secs vs. 30secs) with cgi. I can do without the antialiasing features of rrdtool 1.2.

Is it possible that OpenWrt binaries do work on Olegs firmware?
It will depend on the runtime libaries used, I think...

Oleo:

rrdtool create loadavg.rrd --step 60 DS:load1:GAUGE:120:0:U \
DS:load5:GAUGE:120:0:U DS:load15:GAUGE:120:0:U RRA:AVERAGE:0.5:1:2160

...does work too.

[MMCM]

my /usr/bin/rrdtool binary links with /lib/ld-uClibc.so.0 which is a symlink to /lib/ld-uClibc-0.9.28.so

[oleo]

It looks like this is not uClibc problem.
I've compiled 1.0.50 and it works while 1.2.15 does not.

Shall we downgrade (easy) or find a bug in 1.2.15 (hard)?

[_Denis_]

Everything in the nature takes easy way.

And as said MMCM rrdtool 1.0.50 is much faster in use.

[Oleg]

Yes, downgrade to stable version. Newer does not always means better...

[oleo]

Yes, downgrade to stable version. Newer does not always means better...

I like doing things hard way and started more research on the hang issue of the following one liner with rrdtool-1.2.5:

rrdtool create test1.rrd DS:in:DERIVE:600:0:125000000 RRA:AVERAGE:0.5:1:600

Here are results:

1. nslu2 feed/nslu2 firmware - works
2. oleg feed/oleg firmware - fail
3. ddwrt feed/oleg firmware - fail
4. ddwrt feed/Xwrt firmware - works
5. oleg feed/Xwrt firmware - works

I was doing more research as I've hit to similar problem when upgraded gnuplot from 4.0.0 to 4.2rc2. On oleg firmware gnuplot hang on some plots,
while exactly the same gnuplot worked on OpenWRT (Xwrt).

ipkg-0.99.163 is more restrictive on packages that came from different package feeds! Removing gnuplot record from /opt/lib/ipkg/lists/optware is necessary!

root@OpenWrt:/opt/tmp$ wget http://ipkg.nslu2-linux.org/feeds/optware/oleg/cross/stable/gnuplot_4.2.rc2-1_mipsel.ipk
Connecting to ipkg.nslu2-linux.org[140.211.166.82]:80
gnuplot_4.2.rc2-1_mi 100% |*****************************|   890 KB 00:00:00 ETA
root@OpenWrt:/opt/tmp$ /opt/bin/ipkg install gnuplot_4.2.rc2-1_mipsel.ipk
Installing gnuplot (4.2.rc2-1) to opt...
Nothing to be done
Successfully terminated.
Collected errors:
Package gnuplot md5sum mismatch. Either the ipkg or the package index are corrupt. Try 'ipkg update'.
root@OpenWrt:/opt/tmp$ vi /opt/lib/ipkg/lists/optware
root@OpenWrt:/opt/tmp$ /opt/bin/ipkg install gnuplot_4.2.rc2-1_mipsel.ipk
Installing gnuplot (4.2.rc2-1) to opt...
Configuring gnuplot
Successfully terminated.

Same results were obtained also for gnuplot 4.2rc2 hang problem. Downgrading to 4.0.0 on oleg firmware with

wget http://ipkg.nslu2-linux.org/feeds/op...0-1_mipsel.ipk
ipkg install -force-downgrade gnuplot_4.0.0-1_mipsel.ipk

restored normal gnuplot bahaviour.

The difference between oleg and ddwrt is just in kernel headers. All packages are built upon exactly the same toolchain and config.

My conclusion is, that the problem is within Oleg firmware and not the packages itself. More precisely; I do not blame linux 2.4.20 kernel sources for this. I thing that the problem is that oleg firmware is built with old 0.9.19 uClibc built with old 3.2.3 toolchain.

Having all this in mind I must repeat the question:

Shall we downgrade (easy), or find a bug (hard)?

[Oleg]

That' strange: your apps are linked against your uclibc, so my firmware is not involved at all. Btw, have you tried using linux headers from the broadcom toolchain?

[oleo]

Headers were extracted from broadcom toolchain when I was creating buildroot toolchain.

They are located at http://www.wlan-sat.com/boleo/optware/
See http://trac.nslu2-linux.org/optware/...e/buildroot.mk
for details.

On Xwrt you can install either package (oleg|ddwrt) and it works. So the problem must be with firmware itself.