Mathieu Monfort | 1 Apr 11:04 2003
Picon

autoscale pb

hi all!
when i graph my rrd content, i have -u 78609408 and the max value become 80 M, how can i have the exact value 78,6M??
does autoscale can help me? i don't think so.
Mathieu
--
Unsubscribe mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

Mathieu Monfort | 1 Apr 11:43 2003
Picon

graph with a constant value

hi,
i try to graph a snmp disk usage in a multigraph with the usage by snmp in the rrd and the disk total space as a
constant value in stade of stocking it in a rrd (it would expand the rrd file size)
how can i make it??
thanks 
Mathieu
--
Unsubscribe mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

Jake Brutlag | 2 Apr 00:53 2003
Picon

Fixing the Win32 Build


Prompted by Ian Holsman's great work, I've fixed the Win32 Build on VC++
6.0 (including compiling/testing perl shared). I've also incorporated
Ian's rrd.vcproj file, so everything should work with VC++ 7.0 as well.
The default on the Win32 platform (VC++ 6.0 and 7.0) is now to use the
thread-safety code (rrd_thread_safe_nt.c), though I haven't done any
testing in a multi-threaded environment.

Note for those compiling perl-shared: I added a reference to
$ENV{'MSVCDir'} in ntmake.pl. This means you will need to run
VCVARS32.BAT (included w/ VC++ 6.0) before "perl ntmake.pl".

Feedback is always welcome. Here's to hoping the Win32 build will still
be working in 6 months!

Jake

Jake Brutlag
Network Analyst
TV Services -- Network Operations
Microsoft MSN 

--
Unsubscribe mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

Tobias Oetiker | 3 Apr 23:32 2003
Picon
Picon

Re: rrdtool libraries segfault with getopt

Today Markus Baertschi wrote:

>
> I'm developping an app in C which is calling rrd_update and rrd_create
> directly (linking with librrd). So far things are working, but there
> is a problem if I mix calls to rrd_create and rrd_update. The rrd_update
> call generates a segfault and my app is dead :-(.

how about using rrd_cgi.c or rrd_tool.c as an example? see how
optind gets reset ?

cheers
tobi
--

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker  <at>  ISG.EE, ETZ J97, ETH, CH-8092 Zurich
 / // _ \/ _ \/ /  System Manager, Time Lord, Coder, Designer, Coach
/_/ \.__/_.__/_/   http://people.ee.ethz.ch/~oetiker   +41(0)1-632-5286

--
Unsubscribe mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request <at> list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

Peter Stamfest | 4 Apr 06:42 2003
Picon

Re: rrdtool libraries segfault with getopt

On Thu, 3 Apr 2003, Markus Baertschi wrote:

> Date: Thu, 03 Apr 2003 22:31:49 +0200
> From: Markus Baertschi <markus <at> markus.org>
> To: "rrd-developers <at> list.ee.ethz.ch" <rrd-developers <at> list.ee.ethz.ch>
> Subject: [rrd-developers] rrdtool libraries segfault with getopt
> 
> 
> I'm developping an app in C which is calling rrd_update and rrd_create
> directly (linking with librrd). So far things are working, but there
> is a problem if I mix calls to rrd_create and rrd_update. The rrd_update
> call generates a segfault and my app is dead :-(.
> 

[ snip ] 

> 
> Any ideas ?

This is one of the things the thread-safety stuff tries to solve as well. 
Thus you might want to use the 1.1 development tree. There the trick is 
to use rrd_create_r and rrd_update_r. These functions bypass getopt. You 
only have to call rrd_clear_error before you call any of the *_r 
functions. I _think_ you do not even need the entire thread-safety stuff 
(ie. linking with librrd_th and libpthread) and it should work with librrd 
as well.

peter

--
(Continue reading)

Brian_Teravskis | 4 Apr 15:44 2003

Re: rrdtool libraries segfault with getopt

Markus,
I had a similar problem about two weeks ago and I found that I had to
set optind (a global variable) to zero every time you call an rrd
functions. Example:

optind = 0; opterr = 0;

  if( ::rrd_create(len, temp_create_string) ) {

[...]

My feeling is this should be done in the library, or a library function
should be provided to do this. As you can see I also set the variable
opterr to zero as well. If you look at the php rrd code you will see the
same technique.

I hope this helps.

Regards and good luck,

Brian

-----Original Message-----
From: markus <at> markus.org [mailto:markus <at> markus.org]
Sent: Thursday, April 03, 2003 2:32 PM
To: rrd-developers <at> list.ee.ethz.ch
Subject: [rrd-developers] rrdtool libraries segfault with getopt

I'm developping an app in C which is calling rrd_update and rrd_create
directly (linking with librrd). So far things are working, but there
(Continue reading)

Markus Baertschi | 4 Apr 19:54 2003

Re: rrdtool libraries segfault with getopt


Tobi,

I've done some experimenting and can found, that the rrd_* routines
require that the optind variable is set to zero before calling them.
If you use getopt the optind variable points to the last argument
in your respective argv after the array is processed. Getopt picks
up where it left using this method. As this is standard unix proctice
, I feel that the rrd_* routines should reset optind to zero before 
getopt processing. 
One could argue the user of getopt should reset optind to zero after
each usage of getopt, but I've never seen this done. At the moment 
the rrd_* routines assume that getopt is zero, which breaks them for
any program using getopt itself.

Brian, Peter,

thanks for your input. For now I stick to my workaround. I've had a look
at 1.1 and found that it has no feature I would need and my 1.0 setup
is working.

Regards Markus

On Thu, 3 Apr 2003 23:32:30 +0200 (MEST), Tobias Oetiker wrote:

>Today Markus Baertschi wrote:
>
>>
>> I'm developping an app in C which is calling rrd_update and rrd_create
>> directly (linking with librrd). So far things are working, but there
(Continue reading)

Peter Stamfest | 4 Apr 20:17 2003
Picon

Re: rrdtool libraries segfault with getopt


On Fri, 4 Apr 2003, Markus Baertschi wrote:

> Date: Fri, 04 Apr 2003 19:54:40 +0200
> From: Markus Baertschi <markus <at> markus.org>
> To: Tobias Oetiker <oetiker <at> ee.ethz.ch>
> Cc: "rrd-developers <at> list.ee.ethz.ch" <rrd-developers <at> list.ee.ethz.ch>
> Subject: [rrd-developers] Re: rrdtool libraries segfault with getopt
> 
> 
> Tobi,
> 
> I've done some experimenting and can found, that the rrd_* routines
> require that the optind variable is set to zero before calling them.
> If you use getopt the optind variable points to the last argument
> in your respective argv after the array is processed. Getopt picks
> up where it left using this method. As this is standard unix proctice
> , I feel that the rrd_* routines should reset optind to zero before 
> getopt processing. 
> One could argue the user of getopt should reset optind to zero after
> each usage of getopt, but I've never seen this done. At the moment 
> the rrd_* routines assume that getopt is zero, which breaks them for
> any program using getopt itself.

True.

On a more general level I consider any repeated use of getopt "broken" in
any case, as one can never be sure what a particular getopt implementation
is _really_ doing behind the scenes. As long as one deals with just one 
particular implementation a work-around is fine, but when the porting 
(Continue reading)

Peter Stamfest | 5 Apr 07:09 2003
Picon

Re: rrdtool libraries segfault with getopt

On Fri, 4 Apr 2003, Tobias Oetiker wrote:

> Date: Fri, 4 Apr 2003 23:01:03 +0200 (MEST)
> From: Tobias Oetiker <oetiker <at> ee.ethz.ch>
> To: Peter Stamfest <peter <at> stamfest.at>
> Subject: Re: [rrd-developers] Re: rrdtool libraries segfault with getopt
> 
> Today Peter Stamfest wrote:
> >
> > I think this all started with the creation of "librrd", a really great
> > idea, but the understandable design decision to rely on getopt for
> > variable length argument handling within the stand-alone tools turned sour
> > when those tools ended up together in the library. This is "living
> > history" we deal with here.

Just to clarify things: I can absolutely understand how this started. That
is how such projects work. You always end up with something suboptimal.  
This is natural. I cannot think of a single of my projects where
_everything_ went smoothly and the end-product was perfect. If I am not
satisfied I tend to rewrite whole applications... ;-) I would not do this
with the rrdtool, however. Conclusion: Early design decisions often tend 
to get in the way of a project later on.

> 
> If one of you wants to designe a more 'reasonable' calling
> interface for the rrdtool functions, please post your plan to the
> rrd-developers list ... (and later send a patch :-) )

I am not saying that the current implementation is bad: It has its
problems, but for some areas there are now replacements/extensions (the
(Continue reading)

Tobias Oetiker | 5 Apr 10:26 2003
Picon
Picon

Re: rrdtool libraries segfault with getopt

Today Peter Stamfest wrote:

> Just to clarify things: I can absolutely understand how this started. That
> is how such projects work. You always end up with something suboptimal.
[...]

sure no problem ...

[...]
> I am not saying that the current implementation is bad: It has its
> problems, but for some areas there are now replacements/extensions (the
> *_r function for some operations do not use getopt for two reasons:
> Non-threadable and as mentioned before: using getopt multiple times is not
> the Right Thing to do).

... and now is the time to change things ... that is what the 1.1.x
branche is for ... realy, I am totally open ... in the same way as
the calling interface would need work, a more generic data output
structure would be sensible I think ... maybe along the lines of
rrd_info ...

> One more thing I want to add to this discussion: There is one problem that
> I encountered recently that partly has to do with the fact that all
> communication to the RRD functions is through strings: RRDs essentially
> store values of type "double". If one wants to put a double value into an
> RRD using all significant places of such a double then things get hairy:
> Who can name a printf-format specifier that garantees that one gets _all_
> significant places? I have no answer how to properly handle this situation
> right now. And communicating through strings also slows down things
> unneccessarily.
(Continue reading)


Gmane