perfparse-devel — Development Issues

[Perfparse-devel] Re: Use of RRD

[Yves M. <yme...@li...>]

> Garry, Yves,
>
> I want to talk about RRD, however I have lost the original thread.
>
> Let me explain my worries about using RRD.  Please correct me where I a=
m
> going wrong.

My comments will be my explanations.
Garry has his own opinion (I agree with him for most of what he said).

>
> Round Robin Database gives a method of storing a fixed period of data
> which is stored locally and may be graphed by many available open sourc=
e
> programs.  This is a fast self-purging method liked by many people.
>
> But what are we proposing?
>
> i) Using just RRD.
>
> ii) Using RRD for storage of Binary data, and a DBMS for everything els=
e.
>
> iii) Using PP as is, but also store data in RRD.

iv) Using RRD for storage of Binary data, and a DBMS for *all*

Well, propose everything !
Some may only use the perfparse binary (not the CGI...) to create RRD fil=
es and use them
with other tools. Some may need database storage. Some may need both...

I my mind, there is only a --rrd-dump=3Drrdfile option to add in perfpars=
e.c and to support.
Those who want to graph the data from the rrdfile will use their own tool=
s, and maybe
some may send us a contribution ?

> I have seen some comments about using (i), just RRD.
>
> If we do this, the product we will have effectively is not PerfParse.
> - There will be no storage of raw data.

For now, this is not a problem for me: I use only binary data.

> - The extra information we plan, like a range of WARN and CRITICAL
> values will not be supported.

This is a choice I can do for here. My need is that the extra information=
s are parsed. I
don't mind they are not stored.
And there is a hack we can do: store them as another value. The rrdfile w=
ill grow
faster, with 5 values instead of 1 (val, warnmin, warnmax, critmin, critm=
ax)

> - The product will not be client/server, and therefore the whole of PP
> must be using on a single machine.

I need this. So I need the database (except if we make another server/cli=
ent system, but
this is not planned, and we have enough of them for now)

>
> Effectivelly, the entire PP CGI is redendent and we should probably
> advise users to use one of the existing mature RRD viewers.  This will
> mean that PP is reduced to just the 'perfparse' program, which it's sel=
f
> is reduced to just storing binary values in an RRD database.
>
> I don't think we want to do this. :)

I think that some want it. You would not have so many mails about it othe=
rwise.

> With option (ii), using RRD for the binary data.  This also presents
> some problems:
>
> - Extra data, like range of WARN and CRIT cannot be supported in full.
> Although two lines for each can be stored to indicate range.  Messy!

The users make the choice.

> - Half of PP is client/server, half is local.

This is good for data storage. Few data central, a lot of data on each mo=
nitored machine.
If the CGI could ask each monitored machine for the data, it would be bet=
ter for data
storage : save the data with your usual backup procedure. It would also b=
e better for
network traffic: only the needed values go on the network.
Sadly, it is more complex to implement this because of the client-server =
issue.

> - Referential Integrity is hard to maintain using two different databas=
e
> types.
> - Lots of re-coding to get the chart to read RRD data.

About this: probably like you, I fully disagree about the CGI reading RRD=
 data.
I agree with feeding RRD files, but exploitation of RRD files has to be d=
one with other
tools (that can be part of the perfparse project, one day, why not ?)

> Again, I wonder whether this is worth it, although there might be an
> argument.
>
>
> My feeling is that we should provide an option the user can select when
> compiling:
>
> 1. Store data as RRD for their own use, or not.
> 2. Store data as PP format, or not.

Yes :)
My own reflexion results in the same conclusion :)

Yves
>
> In the second case, we are effectively providing a method to import dat=
a
> into RRD, and the users chooses not to use any of the other features we
> provide.
>
> As always, I look forward to your comments.
>
> Ben
>
>
>
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Re: Suggested change to the data structure

[Yves M. <yme...@li...>]

I read the previous mail very quick. I may say things that were already s=
aid.
Only one comment at then end...

> A revision to suggested alternate structure for storage of binary data.
>
> This adds another four bytes to the binary file, and a foreign key.
> This correctly respects SQL conversions.  This is still drastically les=
s
> than we currently have, and is therefore still faster and smaller.
>
>
> 1.  Table to hold binary data:
>
> CREATE TABLE perfdata_binary (
>      mid INTEGER NOT NULL,
>      ctime DATETIME NOT NULL,
>      PRIMARY KEY (mid, ctime),
>      value FLOAT NOT NULL,
>      extra_data_id INT,
>      INDEX extra_id_idx (extra_data_id),
>      FOREIGN KEY (extra_data_id)
>          REFERENCES perfdata_binary_extra (extra_data_id)
>          ON DELETE SET NULL
> )
>
>
> 2. Table to hold extra data:
>
> CREATE TABLE perfdata_binary_extra (
>      extra_data_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
>      mid INTEGER NOT NULL,
>      INDEX mid_idx (mid),
>      FOREIGN KEY (mid)
>          REFERENCES perfdata_service_metric (mid)
>          ON DELETE CASCADE
>      warn_type ENUM ('none','inside','outside') NOT NULL,
>      warn_low FLOAT,
>      warn_high FLOAT,
>      crit_type ENUM ('none','inside','outside') NOT NULL,
>      crit_low FLOAT,
>      crit_high FLOAT,
>      max FLOAT,
>      min FLOAT,
>      raw_data_hash UNSIGNED LONG
> )
>
> To get all fields fields, the following can be used:
>
> SELECT * FROM perfdata_binary JOIN perfdata_binary_extra
>      ON perfdata_binary.extra_data_id =3D
>          perfdata_binary_extra.extra_data_id
>
> This can be added as a VIEW when MySQL supports these.
>
>
> 3. The current (last added) record for each metric.
>
> The current record pointed to in the perfdata_service_metric table will
> hold the 'ctime' pointing to the perfdata_binary table.  This table als=
o
> holds the Metric ID (mid) so that a correct start on the primary key is
> possible:
>
> SELECT * FROM perfdata_binary
>      WHERE mid =3D perfdata_service_metric.mid
>      AND ctime =3D perfdata_service_metric.last_perfdata_bin
>
>
>
> 4. The procedure for adding new binary data:
>
> i) Locate the extra data record from the current exiting binary record.
>
> ii) If changes required, a new record to be created.

Yes, I agree with that. However, won't the check take too much time ?

> Because of problems comparing FLOAT and DOUBLE values using '=3D=3D',
> compare a hash of raw ascii performance data to hash value in table.
>
> Eg: raw_data_hash =3D hash("102:103;@1232:2343.244;0;3000");

Besides fixing problems of comparaison, this also speeds up the search: y=
ou test on only
one key, not on all.

I have a question: is hash() injective ? I mean : how many arguments can =
you give to
hash() to have the same value ? If the answer is 1, it will work well (is=
 injective, and
maybe even bijective). If the answer is "can be more than 1", you also ha=
ve to test the
other values to check if the record already exist, and if yes, which one.

Well, that's all for now. I'm looking forward 0.99.09 (or 0.99.10 if 0.99=
.09 is my
latest 0.99.08ymX) with the new tables !
I prefer not doing it because you have a better idea than me on how this =
can be
implemented, and I prefer that only one work on it.
If you want, I can work on the perfparse binary, on the line scanner. But=
 if I do it, I
want that we freeze the code and work only on that. Otherwise, it will be=
 a mess like we
have never had :)

Yves

>
> iii) Add new extra data record if appropriate.
>
> iv) Add the binary data record.
>
>
>
> Apart from this, the same notes apply as previous posting.
>
>
> Ben
>
>
>
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Suggested change to the data structure

[Ben C. <Be...@cl...>]

A revision to suggested alternate structure for storage of binary data.

This adds another four bytes to the binary file, and a foreign key. 
This correctly respects SQL conversions.  This is still drastically less 
than we currently have, and is therefore still faster and smaller.


1.  Table to hold binary data:

CREATE TABLE perfdata_binary (
     mid INTEGER NOT NULL,
     ctime DATETIME NOT NULL,
     PRIMARY KEY (mid, ctime),
     value FLOAT NOT NULL,
     extra_data_id INT,
     INDEX extra_id_idx (extra_data_id),
     FOREIGN KEY (extra_data_id)
         REFERENCES perfdata_binary_extra (extra_data_id)
         ON DELETE SET NULL
)


2. Table to hold extra data:

CREATE TABLE perfdata_binary_extra (
     extra_data_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
     mid INTEGER NOT NULL,
     INDEX mid_idx (mid),
     FOREIGN KEY (mid)
         REFERENCES perfdata_service_metric (mid)
         ON DELETE CASCADE
     warn_type ENUM ('none','inside','outside') NOT NULL,
     warn_low FLOAT,
     warn_high FLOAT,
     crit_type ENUM ('none','inside','outside') NOT NULL,
     crit_low FLOAT,
     crit_high FLOAT,
     max FLOAT,
     min FLOAT,
     raw_data_hash UNSIGNED LONG
)

To get all fields fields, the following can be used:

SELECT * FROM perfdata_binary JOIN perfdata_binary_extra
     ON perfdata_binary.extra_data_id =
         perfdata_binary_extra.extra_data_id

This can be added as a VIEW when MySQL supports these.


3. The current (last added) record for each metric.

The current record pointed to in the perfdata_service_metric table will 
hold the 'ctime' pointing to the perfdata_binary table.  This table also 
holds the Metric ID (mid) so that a correct start on the primary key is 
possible:

SELECT * FROM perfdata_binary
     WHERE mid = perfdata_service_metric.mid
     AND ctime = perfdata_service_metric.last_perfdata_bin



4. The procedure for adding new binary data:

i) Locate the extra data record from the current exiting binary record.

ii) If changes required, a new record to be created.

Because of problems comparing FLOAT and DOUBLE values using '==', 
compare a hash of raw ascii performance data to hash value in table.

Eg: raw_data_hash = hash("102:103;@1232:2343.244;0;3000");

iii) Add new extra data record if appropriate.

iv) Add the binary data record.



Apart from this, the same notes apply as previous posting.


Ben

[Perfparse-devel] RE: Problems with data structure

[Cook, G. <GW...@ma...>]

Ben Clewett wrote:
> Garry, Yves,
>=20
> To address the two problems Yves found:
>=20
> 1.	Range values for Warn and Crit not supported.
> 2.	Only store the last found value for Max and Min.
>=20
> I propose a new data structure for the Binary data which will also
> increase the speed of the queries and lower the size of the
> data files.
[snip]=20
> ---------------------------------------------------
>=20
> Alternatively, we can hack the existing binary table.  But
> it's a mess
> already.  Biting the bullet one more time before version 1.0.0 might
> make all the difference....=20
>=20
> Regards, Ben.

I won't pretend to understand all of that, but I think I grok enough of
it.
It sounds like a good plan to me.
Most of the time I don't think we will see a range for WARN/CRIT,
although it is important to treat it properly when we do. I also feel
that most of the time MIN/MAX will be NULL, but also needs to be treated
properly.

The MIN/MAX will be used to scale the graphs, correct?
If so, you'll only need to figure out a CRIT-based formula for autoscale
when MIN/MAX is NULL.
Unless of course UOM=3D'%', in which case MIN/MAX may be omitted by =
plugin
developers and should be assumed - 0/100.

Garry W. Cook, CCNA
Network Infrastructure Manager
MACTEC, Inc. - http://www.mactec.com/
303.308.6228 (Office) - 720.220.1862 (Mobile)

[Perfparse-devel] Problems with data structure

[Ben C. <be...@cl...>]

Garry, Yves,

To address the two problems Yves found:

1.	Range values for Warn and Crit not supported.
2.	Only store the last found value for Max and Min.

I propose a new data structure for the Binary data which will also 
increase the speed of the queries and lower the size of the data files.

This will require a heavy conversion, but may make a lot of difference.

This will be done through two ideas:

1.	Key the binary data on a Metric ID (MID) and not on (Host, Service, 
Metric).  This will give a far smaller and faster key structure.

2.	Remove all recurring data from the binary file to a second file.  A 
process I call anti-normalization.


This can be done as follows:


1. Two new tables will be used to replace the one binary table we 
currently use.  The first if which is:

CREATE TABLE perfdata_binary (
	mid INTEGER NOT NULL,
	ctime DATETIME NOT NULL,
	PRIMARY KEY (mid, ctime),
	value FLOAT NOT NULL
)

Each record in now only 12 bytes long, plus the external key.  Therefore 
a months data at a frequency of one minute will be half a meg, plus key 
data.  This is considerably less than the 73 bytes currently used.  (If 
new fields for the range were to be added, then this would add another 
12 bytes, making 85 bytes per record!)


2. The second table will contain the extra information, stuff which only 
occasionally changes:

CREATE TABLE perfdata_binary_extra (
	mid INTEGER NOT NULL,
	ctime DATETIME NOT NULL,
	PRIMARY KEY (mid, ctime),
	warn_type ENUM ('none','inside','outside') NOT NULL,
	warn_low FLOAT,
	warn_high FLOAT,
	crit_type ENUM ('none','inside','outside') NOT NULL,
	crit_low FLOAT,
	crit_high FLOAT,
	max FLOAT,
	min FLOAT
)

The frequency of this second table may be as low as once a month. 
Therefore a months samples can be JOINed to one record of the second 
table.  This will result in faster queries from less data, using:

SELECT * FROM perfdata_binary, perfdata_binary_extra
	WHERE perfdata_binary.mid = perfdata_binary_extra.mid
	AND perfdata_binary.ctime >= perfdata_binary_extra.ctime

The 'state' information currently stored will be calculated.  This will 
be done in code-space today, and later with an embedded function when we 
get to MySQL version 5.  This is not the same as the State stored 
against the raw data.


3. The field 'mid' needs adding to perfdata_service_bin:

AMEND TABLE perfdata_service_bin
	ADD mid INTEGER DEFAULT NULL;
AMEND TABLE perfdata_service_bin
	ADD UNIQUE INDEX mid_idx (mid);

This needs populating from zero to the number of metrics so that no 
record is NULL.


4.	A foreign key needs to be added from the new tables to this.


5.	The 'last_perfdata_bin' field on perfdata_service_bin needs to be 
pointed at the correct tables.  This will require a careful conversion!


6.	The delete policies need changing to delete from these tables.

7.	The CGI needs to be altered to read these new files.

8.	The old binary tables can be dropped.

---------------------------------------------------

Alternatively, we can hack the existing binary table.  But it's a mess 
already.  Biting the bullet one more time before version 1.0.0 might 
make all the difference....

Regards, Ben.

[Perfparse-devel] version 0.99.08ym3

[Yves M. <yme...@li...>]

Hi all !

Beta-testers can test perfparse-0.99.08ym3 from
http://ymettier.chez.tiscali.fr/perfparse-devel/
0.99.08ym2 fixes some bug with new hosts (see my previous post here) and =
0.99.08ym3 has
nearly no change

0.99.08ym3 should become 0.99.09 when Ben comes back from holidays, with =
his add-ons. So
report any bugs to at least him and me.

I will not answer the mail before Monday 16th: I'm going on holidays too =
!

Thanks in advance!
Yves


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Bug when adding new host (update)

[Yves M. <yme...@li...>]

Update...

perfparse-0.99.08

If your CGI is broken after running perfparse for the first time on a new=
 host, yes,
this is a bug !

Either download perfparse-0.99.08ym2 from
http://ymettier.chez.tiscali.fr/perfparse-devel/index.php (with other cha=
nges and other
really minor bugfix: see ChangeLog)

Or:

Edit perfparse/perfparse.c line 1105 and, as a quick and temporary fix, r=
ead "0.13"
instead of VERSION. Then recompile.

Yves
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
This was in the previous post and is still valid.


If your CGI is already broken, you can use your mysql client:
select * from perfdata_state;
domain   | file_name             | line_in_file | last_line_hash | pid  |
perfparse_version 00000001 | /path/serviceperf.log | 0            |      =
          |
1234 | 0 00000002 | /path/serviceperf.log | 0            |               =
 | 4321 | 0.13

The line with perfparse_version =3D 0 has to be updated:
UPDATE perfdata_state SET perfparse_version =3D 0.13 where domain =3D '00=
000001';

That's it. I have not checked it perfparse-db-tool --update works in this=
 case. Sorry
for the bug!

Yves


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com - - GP=
G key     -
http://ymettier.free.fr/gpg.txt                    - - Maitretarot -
http://www.nongnu.org/maitretarot/                 - - GTKtalog    -
http://www.nongnu.org/gtktalog/                    -





--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Bug when adding new host

[Yves M. <yme...@li...>]

perfparse-0.99.08

If your CGI is broken after running perfparse for the first time on a new=
 host, yes,
this is a bug !

Either download perfparse-0.99.08ym1 from
http://ymettier.chez.tiscali.fr/perfparse-devel/index.php (with other cha=
nges and other
really minor bugfix: see ChangeLog)

Or:

Edit perfparse/perfparse.c line 1105 and read DB_VERSION instead of VERSI=
ON. Then
recompile.

If your CGI is already broken, you can use your mysql client:
select * from perfdata_state;
domain   | file_name             | line_in_file | last_line_hash | pid  |=
 perfparse_version
00000001 | /path/serviceperf.log | 0            |                | 1234 |=
 0
00000002 | /path/serviceperf.log | 0            |                | 4321 |=
 0.13

The line with perfparse_version =3D 0 has to be updated:
UPDATE perfdata_state SET perfparse_version =3D 0.13 where domain =3D '00=
000001';

That's it. I have not checked it perfparse-db-tool --update works in this=
 case.
Sorry for the bug!

Yves


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] New (unofficial) release 0.99.07ym5

[Yves M. <yme...@li...>]

Hi,

Ben and I are going on holiday soon.
Besides this, there were a lot of new releases these weeks.
Well, it will be a little more quiet for 2 weeks :)

We also want to try to give you a stable release that we don't modify eve=
ry day. We are
still waiting for Garry who is writing the doc. If you don't mind not hav=
ing the doc,
you can get my latest package here:
http://ymettier.chez.tiscali.fr/perfparse-devel/perfparse-0.99.07ym5.tar.=
gz

Ben should release 0.99.08 soon, maybe today, and 0.99.08 should be 0.99.=
07ym5 including
Garry's doc.

This version is unofficial, which means unsupported. But if there is any =
problem, and if
0.99.08 is not released yet, maybe we can fix the problem before releasin=
g 0.99.08.

I will continue to use this web site for some other releases when we need=
 feedback,
instead of having a new version every day.

In 0.99.07ym5 and in 0.99.08, you will need to update the database, runni=
ng
perfparse-db-tool --update. If you do it with 0.99.07ym5, you don't need =
to do it with
0.99.08.


Any questions ? Well, just ask, until tomorrow (Jul 30th) for Ben, and un=
til Wednesday
(4th Aug). We should be back something like Aug 16th with a lot of mails =
to read.

Yves




--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

Re: [Perfparse-devel] Re: Coding perfdata

[Ben C. <Be...@cl...>]

Yves,

Thanks for the work.   This is about to be released.

Can I ask all to check their 'drop' file to ensure no valid, or nearly 
valid, plugin's end up here.  If they do, please report this to this groups.

Ben

Yves Mettier wrote:

> Hi Garry, William... !
> 
> I just sent Ben my patch 0.99.01ym5 that should become 0.99.02 tomorrow.
> It has some bugs fixed, and a new feature: the quotes are now handled as specified in
> nagios doc.
> label=value
> 'label'=value -> correct
> 'label with spaces ''nd quotes'=value -> correct
> "label"=value -> correct, but notice that "label" is equivalent to '"label"' and not to
> label :)
> 
> For Garry who maintains the documentation, there is a new option in the config file:
> Accept_Odd_Chars_in_Label: if you say yes, this is nagios behaviour. If you say no
> (default answer), characters below ' ' are illegal characters.
> In previous versions of perfparse, they were already illegal characters. Because this is
> not specified in nagios doc, I added this option.
> 
> Now, what is not done:
> 1: "label = value"
> 2: 'label' = value
> 3: label = value
> 
> I think that 'label'= value should work. The code allow this with a space char after the
> label.
> The 2/ and 3/ should be allowed. Maybe I will work on this one day.
> The 1/ has no interest, hasn't it ? You are supposed to quote texts, not expressions.
> Expressions are usually inside brackets or parens. But what is the interest to have it
> here ?
> 
> Now, if someone needs another syntax, it is possible to implement it: we want perfparse
> flexible !
> 
> Yves
> 
> 
> 
>>William,
>>
>>The documentation, as you say, states:
>>
>>'label'=value[UOM];[warn];[crit];[min];[max]
>>
>>However, PerfParse is very flexible.  As so many 'official' plugins
>>don't  provide the correct syntax, it will accept just about anything.  Eg:
>>
>>"label=value" or even "label = value"
>>
>>With any unit (time/seconds/space/latency/users etc) you want, or none.
>>
>>However, PerfParse does not support the '' escapement.
>>
>>Eg, label = "metric's" should -> "'metric''s'"
>>
>>But PerfParse will read this as "'metric''s'" and not "metric's". :)
>>
>>This is not a problem as no plugins currently use this.  It is on our
>>TODO list for future versions.
>>
>>However if you plan to use other tools than PerfParse, you may wish to
>>stick to the official where ever possible.
>>
>>I hope this is of some use,
>>
>>Regards, Ben.
>>
>>
>>Williams, P. Lane wrote:
>>
>>
>>>I guess that's what I get for not following coding guidelines.  Easy enough
>>>though.
>>>
>>>In the nagios performance guidelines, the data should look like
>>>
>>>'label'=value[UOM];[warn];[crit];[min];[max]
>>>
>>>Based on your example below....lets say with my disk data....My performance
>>>output should look like
>>>
>>>'C-total'=value 'C-free'=value 'C-used'=value;warn;crit;min;max
>>>
>>>Which I can exclude everything to the right of the semi-colon, if I wish?
>>>
>>>Is this correct?
>>>
>>>Thanks,
>>>
>>>Lane
>>>
>>>-----Original Message-----
>>>From: Ben Clewett [mailto:Be...@cl...]
>>>Sent: Monday, July 19, 2004 4:13 AM
>>>To: Williams, P. Lane
>>>Subject: Re: Coding perfdata
>>>
>>>
>>>You can include as many metrics as you like in the performance data.
>>>You do have to use the correct syntax, which si explained here:
>>>
>>>http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185
>>>
>>>In it's simplest form, use:
>>>
>>>plugin output | metric1=12 metric2=54 metric3=43512.23432seconds
>>>
>>>I am glad you enjoy the product,
>>>
>>>Regards,
>>>
>>>Ben.
>>>
>>>
>>>Williams, P. Lane wrote:
>>>
>>>
>>>
>>>>Is there a certain way I should format the output of the performance
>>>>data.  My performance data output contains more than just one value.
>>>>Such as my diskspace contains ....total=500,free=300,used=200.  Is only
>>>>one value allowed when using perfparse?  Would it be possible to include
>>>>in the perfparse code a means for the code to detect multiple values and
>>>>process accordingly.  I am not a big C coder, but I believe it could be
>>>>done.
>>>>
>>>>This is a neat concept for Nagios.  I see a lot of potential for this
>>>>app. Thanks, Lane
>>>>
>>>
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>_______________________________________________
>>Perfparse-devel mailing list
>>Per...@li...
>>https://lists.sourceforge.net/lists/listinfo/perfparse-devel
>>
>>
> 
> 
> 

Re: [Perfparse-devel] Re: Coding perfdata

[Yves M. <yme...@li...>]

Hi Garry, William... !

I just sent Ben my patch 0.99.01ym5 that should become 0.99.02 tomorrow.
It has some bugs fixed, and a new feature: the quotes are now handled as =
specified in
nagios doc.
label=3Dvalue
'label'=3Dvalue -> correct
'label with spaces ''nd quotes'=3Dvalue -> correct
"label"=3Dvalue -> correct, but notice that "label" is equivalent to '"la=
bel"' and not to
label :)

For Garry who maintains the documentation, there is a new option in the c=
onfig file:
Accept_Odd_Chars_in_Label: if you say yes, this is nagios behaviour. If y=
ou say no
(default answer), characters below ' ' are illegal characters.
In previous versions of perfparse, they were already illegal characters. =
Because this is
not specified in nagios doc, I added this option.

Now, what is not done:
1: "label =3D value"
2: 'label' =3D value
3: label =3D value

I think that 'label'=3D value should work. The code allow this with a spa=
ce char after the
label.
The 2/ and 3/ should be allowed. Maybe I will work on this one day.
The 1/ has no interest, hasn't it ? You are supposed to quote texts, not =
expressions.
Expressions are usually inside brackets or parens. But what is the intere=
st to have it
here ?

Now, if someone needs another syntax, it is possible to implement it: we =
want perfparse
flexible !

Yves


> William,
>
> The documentation, as you say, states:
>
> 'label'=3Dvalue[UOM];[warn];[crit];[min];[max]
>
> However, PerfParse is very flexible.  As so many 'official' plugins
> don't  provide the correct syntax, it will accept just about anything. =
 Eg:
>
> "label=3Dvalue" or even "label =3D value"
>
> With any unit (time/seconds/space/latency/users etc) you want, or none.
>
> However, PerfParse does not support the '' escapement.
>
> Eg, label =3D "metric's" should -> "'metric''s'"
>
> But PerfParse will read this as "'metric''s'" and not "metric's". :)
>
> This is not a problem as no plugins currently use this.  It is on our
> TODO list for future versions.
>
> However if you plan to use other tools than PerfParse, you may wish to
> stick to the official where ever possible.
>
> I hope this is of some use,
>
> Regards, Ben.
>
>
> Williams, P. Lane wrote:
>
>> I guess that's what I get for not following coding guidelines.  Easy e=
nough
>> though.
>>
>> In the nagios performance guidelines, the data should look like
>>
>> 'label'=3Dvalue[UOM];[warn];[crit];[min];[max]
>>
>> Based on your example below....lets say with my disk data....My perfor=
mance
>> output should look like
>>
>> 'C-total'=3Dvalue 'C-free'=3Dvalue 'C-used'=3Dvalue;warn;crit;min;max
>>
>> Which I can exclude everything to the right of the semi-colon, if I wi=
sh?
>>
>> Is this correct?
>>
>> Thanks,
>>
>> Lane
>>
>> -----Original Message-----
>> From: Ben Clewett [mailto:Be...@cl...]
>> Sent: Monday, July 19, 2004 4:13 AM
>> To: Williams, P. Lane
>> Subject: Re: Coding perfdata
>>
>>
>> You can include as many metrics as you like in the performance data.
>> You do have to use the correct syntax, which si explained here:
>>
>> http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185
>>
>> In it's simplest form, use:
>>
>> plugin output | metric1=3D12 metric2=3D54 metric3=3D43512.23432seconds
>>
>> I am glad you enjoy the product,
>>
>> Regards,
>>
>> Ben.
>>
>>
>> Williams, P. Lane wrote:
>>
>>
>>>Is there a certain way I should format the output of the performance
>>>data.  My performance data output contains more than just one value.
>>>Such as my diskspace contains ....total=3D500,free=3D300,used=3D200.  =
Is only
>>>one value allowed when using perfparse?  Would it be possible to inclu=
de
>>>in the perfparse code a means for the code to detect multiple values a=
nd
>>>process accordingly.  I am not a big C coder, but I believe it could b=
e
>>>done.
>>>
>>>This is a neat concept for Nagios.  I see a lot of potential for this
>>>app. Thanks, Lane
>>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
> _______________________________________________
> Perfparse-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perfparse-devel
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Perfparse segfault on Solaris (fixed)

[Yves M. <yme...@li...>]

Answering to Darren Kemp...

I think I found the bug.
Read my_gethostname() at the beginning of config_file.c. Can you find the=
 malloc() ?
The bug is there: you read malloc(sizeof(MAXHOSTNAMELEN)) instead of
malloc(sizeof(char)*MAXHOSTNAMELEN)
Please change and recompile !

btw, Ben, this bug only happens on Solaris. Linux does not execute that c=
ode.

> Its interesting too, because if I move the config file out of the confi=
g
> dir, it exits normally as it should.
>
> Very strange. When I get some more free time I am going to try this
> compile on a different server.

Not so strange. Here is why:
When there is a buffer overflow somewhere, the program writes data in som=
e places it
should not. If you don't use Electric Fence, it usually writes data on th=
e same memory
page, which is forbidden, but does not generate a segmentation fault.
Writing data after the limit can overwrite other data. Then, those data m=
ean nothing.
And when fgets in our case, or other instruction (often printf) tries to =
do something,
it works with those corrupted data which make the program crash.

Now, the bug is not where it crashes. This is why you usually crash a pro=
gram somewhere
on a system, somewhere else on another system, never on other systems, an=
d in different
places with gdb or Electric Fence. Moreover, if you add printf() to debug=
, it will crash
again in a different place, or even not crash but corrupt the data !

The easy way that does not work all the time is to use gdb. The hard way =
that has always
worked 100% of the time for me is to use Electric Fence and either gdb wi=
th the dumped
core, or printf everywhere in the source code. printf("%s:%d\n", __FILE__=
,__LINE__);
It took me 10 minutes to find our bug when I started to use Electric Fenc=
e !

Now, if you move the config file somewhere else, it exits normally. This =
is because
my_gethostname() did not corrupt the data or the code to test if the file=
 exists and
exit if not. But even if it seemed to work, it was already buggy !

Well, thanks for reporting that bug that I consider as serious.
Please edit config_file.c yourself ASAP, or wait for 0.99.02 that Ben wil=
l probably
release before tomorrow.

Yves

>
> -dkk
>
>
> -----Original Message-----
> From: Yves Mettier [mailto:yme...@li...]
> Sent: Monday, July 19, 2004 2:37 PM
> To: Kemp, Darren
> Cc: be...@cl...
> Subject: RE: [Fwd: RE: [Perfparse-users] FW: Seg fualt]
>
> Ben, don't release 0.99.02 before I have a serious look on that one.
> I don't have the code here at home, but there is something strange...
>
> [...]
>
>> #4  0xff01142c in fgets () from /usr/lib/libc.so.1
>> #5  0xff142668 in conf_load (sFileName=3D0x0) at config_file.c:194
>> #6  0x0001124c in main (argc=3D2, argv=3D0xffbefd14) at perfparse.c:14=
9
> [...]
>> (gdb) p f
>> $2 =3D 0
>
> f should not be nul !!!!!
> There is a test before that makes the program quit if f is null !!! :)
> I'll have a look on that one tomorrow.
>
>
>
>> Dkk> 5.8 Generic_117350-04 sun4u sparc SUNW,Sun-Fire-480R
>
> 5.8 too for me :)
> But I cannot reproduce the bug :(
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Re: Coding perfdata

[Ben C. <Be...@cl...>]

William,

The documentation, as you say, states:

'label'=value[UOM];[warn];[crit];[min];[max]

However, PerfParse is very flexible.  As so many 'official' plugins 
don't  provide the correct syntax, it will accept just about anything.  Eg:

"label=value" or even "label = value"

With any unit (time/seconds/space/latency/users etc) you want, or none.

However, PerfParse does not support the '' escapement.

Eg, label = "metric's" should -> "'metric''s'"

But PerfParse will read this as "'metric''s'" and not "metric's". :)

This is not a problem as no plugins currently use this.  It is on our 
TODO list for future versions.

However if you plan to use other tools than PerfParse, you may wish to 
stick to the official where ever possible.

I hope this is of some use,

Regards, Ben.


Williams, P. Lane wrote:

> I guess that's what I get for not following coding guidelines.  Easy enough
> though.
> 
> In the nagios performance guidelines, the data should look like 
> 
> 'label'=value[UOM];[warn];[crit];[min];[max]
> 
> Based on your example below....lets say with my disk data....My performance
> output should look like
> 
> 'C-total'=value 'C-free'=value 'C-used'=value;warn;crit;min;max
> 
> Which I can exclude everything to the right of the semi-colon, if I wish?
> 
> Is this correct?
> 
> Thanks,
> 
> Lane
> 
> -----Original Message-----
> From: Ben Clewett [mailto:Be...@cl...] 
> Sent: Monday, July 19, 2004 4:13 AM
> To: Williams, P. Lane
> Subject: Re: Coding perfdata
> 
> 
> You can include as many metrics as you like in the performance data. 
> You do have to use the correct syntax, which si explained here:
> 
> http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185
> 
> In it's simplest form, use:
> 
> plugin output | metric1=12 metric2=54 metric3=43512.23432seconds
> 
> I am glad you enjoy the product,
> 
> Regards,
> 
> Ben.
> 
> 
> Williams, P. Lane wrote:
> 
> 
>>Is there a certain way I should format the output of the performance
>>data.  My performance data output contains more than just one value.  
>>Such as my diskspace contains ....total=500,free=300,used=200.  Is only 
>>one value allowed when using perfparse?  Would it be possible to include 
>>in the perfparse code a means for the code to detect multiple values and 
>>process accordingly.  I am not a big C coder, but I believe it could be 
>>done.
>>
>>This is a neat concept for Nagios.  I see a lot of potential for this 
>>app. Thanks, Lane
>>
> 
> 

[Perfparse-devel] Re: Database creation questions

[Chris D. <cdo...@cc...>]

Ben,
In my rush to get the e-mail off, I forgot to attach the scripts. Here 
there are now.
Chris

[Perfparse-devel] Re: Database creation questions

[Ben C. <Be...@cl...>]

Chris,

First off, really glad to hear you are going to have a go at this, I am 
sure PerfParse will be greatly improved by this.

Let me answer in line:

> I've been looking at the database creation scripts. There are some parts 
> of the SQL commands that are not available in Oracle. The differences 
> are significant enough that I am going to create separate create and 
> delete scripts for Oracle and we will likely need to create separate 
> scripts for each database supported because the creation syntax and 
> options can be fairly specific even when the query syntax is the same.

Ok.  The creation script is named using the DBMS name so that others may 
be supplied :)

> The create statements all have an "IF NOT EXISTS" statement. I assume 
> that this causes causes the create statements to not create a table if 
> one already exists but also not generate an error if the table isn't 
> created for that reason.

Not exactly.  If the table exists, no creation takes place and the 
existing table is left in place.

> This isn't an option in Oracle. If the table 
> already exists, Oracle is going to generate an error. The only way 
> around this is drop the table first but if the table doesn't exist, then 
> that will generate an error. Do we need to allow someone to run the 
> create script on top of an already created database? I would prefer to 
> drop each table and then create it. This seems to be the style that is 
> prevalent among Oracle DBAs that I have spoken to.

The advantage of the 'IS NOT EXISTS' is that the script can be run again 
and only create new tables.  But this is flawed.  This syntax does not 
exist for the 'ALTER TABLE' so these parts will fail anyway.

In short, the script is only used on the first install.  It should never 
be used after that.  (Maybe I will add that comment to the head of the 
script as well :)

> In Oracle, the standard way to do a variable length character string is 
> using a VARCHAR2 rather then the VARCHAR. I believe this will still 
> interface in the same way when we do our queries. I have also kept the 
> lengths on them so that the data should be compatible across databases.

Ok.  Yves talked to me about an elegant abstraction layer for multiple 
DBMSs.  I am sure we can turn this idea into a template :)

> Oracle also doesn't have support for the Auto Increment data type so I 
> created a sequences and triggers to do the same thing. Also the foreign 
> key constraint "ON DELETE RESTRICT" is redundant and the syntax not 
> supported in Oracle.

Is the ON DELETE RESTRICT default?  It is default in MySQL, I just like 
adding it for clarity.

> I may have made some other changes between the MySQL scripts and the 
> Oracle scripts but I can't remember right now. I am including a tar.gz 
> file with the two files in them. The files will be placed in the contrib 
> directory right next to the MySQL scripts. Please look them over and 
> send me any questions. I have tested the scripts against an Oracle 
> database so they are syntactically correct and I believe they are 
> programatically correct as well.

I'll take a look and answer in a while.

Regards,

Ben

[Perfparse-devel] Deletion Policy Specification

[Ben C. <Be...@cl...>]

Yves Mettier wrote:

> Replace with:
> =============
> These policies may be passed to their respective objects at the time
> of user-configuration.  However they will also be automatically set
> before the start of the purge for those that do not have a specific policy
> (policy type = "user").

OK.

> Replace with:
> =============
> These are the defaults where the user has no specified
> any other value. If they don't exist, they are automatically created by the purge tool.

OK.

> Replace with:
> =============
> The policy is defined directly into the INT field, either by the user
> or from the template or host policies at purge time.

OK.

> !!!?
> There cannot be any ultimate default. If no value is entered, it means NULL. And NULL
> means "never delete data".
> There will only be a default value set by the configuration tool (the CGI for now).
> There is nothing to implement here. Just say it in the doc :)

I have changed the wording to:

If the type 'user' is used, the default will be offered by the 
configuration tool, currently the CGI interface.

Also included some snap-shots to help new developers.

New doc attached.

Ben

Re: [Perfparse-devel] Re: Storing the STATE from Nagios.

[Yves M. <yme...@li...>]

Some imprecisions:

2. Main table
These policies may be passed to their respective objects at the time
of user-configuration.  However they will also be automatically set
before the start of the purge.

Replace with:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
These policies may be passed to their respective objects at the time
of user-configuration.  However they will also be automatically set
before the start of the purge for those that do not have a specific polic=
y
(policy type =3D "user").



These are used for ultimate defaults where the user has no specified
any other value.

Replace with:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
These are the defaults where the user has no specified
any other value. If they don't exist, they are automatically created by t=
he purge tool.


3. Binary Data Deletion Policy
  'user'
The policy is defined directly into the INT field, either by the user
or from the ultimate default.

Replace with:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The policy is defined directly into the INT field, either by the user
or from the template or host policies at purge time.



If the type 'user' is used, but no value entered, then an ultimate
default will be set.

!!!?
There cannot be any ultimate default. If no value is entered, it means NU=
LL. And NULL
means "never delete data".
There will only be a default value set by the configuration tool (the CGI=
 for now).
There is nothing to implement here. Just say it in the doc :)

Yves





> To developers and documenters of PP,
>
> This email as an attachment of some notes defining how the new Deletion
> Policy will work with version 0.0.12.  This should hopefully be release=
d
> soon.
>
> The CGI work involved in making these policies easily definable for
> users is quite complex.  This will take a few days.  I will need some
> feedback on usability when complete, or we will only confuse our poor
> user base :)
>
> Yves, please review the document for errors. :)
>
> Regards, Ben.
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

Re: [Perfparse-devel] Re: Storing the STATE from Nagios.

[Ben C. <Be...@cl...>]

To developers and documenters of PP,

This email as an attachment of some notes defining how the new Deletion 
Policy will work with version 0.0.12.  This should hopefully be released 
soon.

The CGI work involved in making these policies easily definable for 
users is quite complex.  This will take a few days.  I will need some 
feedback on usability when complete, or we will only confuse our poor 
user base :)

Yves, please review the document for errors. :)

Regards, Ben.

Re: [Perfparse-devel] Re: Storing the STATE from Nagios.

[Yves M. <yme...@li...>]

> Yves Mettier wrote:
>
>> A request has been requested ? Funny :)
>
> Excuse my English!  You should see my French :)

You mean hear or read ?
OK, I stop my critics :)

>> Well, after reading the doc, I still don't get it. Where exactly do we=
 get that value
>> ?
>
> I think the line in nagios.cfg:
>
> xpdfile_service_perfdata_template=3D$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\=
t$OUTPUT$\t$PERFDATA$
>
> Should now be:
>
> xpdfile_service_perfdata_template=3D$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\=
t$OUTPUT$\t$PERFDATA$\t$SERVICESTATE$
>
> But this is untested.

I read something about this in parse_line() in perfparse.c
If this can help any developer to start ?

Yves

--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

Re: [Perfparse-devel] Re: Storing the STATE from Nagios.

[Ben C. <Be...@cl...>]

Yves Mettier wrote:

> A request has been requested ? Funny :)

Excuse my English!  You should see my French :)

> Well, after reading the doc, I still don't get it. Where exactly do we get that value ?

I think the line in nagios.cfg:

xpdfile_service_perfdata_template=$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$OUTPUT$\t$PERFDATA$

Should now be:

xpdfile_service_perfdata_template=$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$OUTPUT$\t$PERFDATA$\t$SERVICESTATE$

But this is untested.


> Well... you can do basic support in 0.0.12 and people will not have to update their
> database twice ?
> 1/ add the field in the database
> 2/ adapt the tools not to crash with this new field
> 3/ update convert.c
> 
> Then perfparse will feed the database with a default value. This makes work easier for
> after.
> 
> 
>>3. Changing perfparse to scan 'nagios.cfg' to check Nagios is using the
>>correct format, and exit on error if not correct.
>>4. Updating the raw data report to display this value.
>>5. Including a 'configure' definition of where to expect the Nagios
>>'etc' directory., default /usr/local/nagios/etc.
> 
> 
> In 0.0.13 or after ?

Definitely after 0.0.12.  Depending on time, developer resources and 
other requirements, hopefully in next 2-3 releases.  But as you say, to 
avoid too many database updates, I can add the field in the current 
release, 0.0.12.

Ben

[Perfparse-devel] Re: Storing the STATE from Nagios.

[Yves M. <yme...@li...>]

> Yves and others:

I can't do it right now... too many things else to do...

> A request to store the plugin state has been requested, the macro name
> is: $SERVICESTATE$, from http://nagios.sourceforge.net/docs/1_0/macros.=
html

A request has been requested ? Funny :)

Well, after reading the doc, I still don't get it. Where exactly do we ge=
t that value ?

> This is probably an oversite not to store this from version 0.01 :)
>
> For some time in the near future, suggest:
>
> 1. Changing perfparse to expect this macro.
> 2. Adding a field to the raw data table to store this value.

Well... you can do basic support in 0.0.12 and people will not have to up=
date their
database twice ?
1/ add the field in the database
2/ adapt the tools not to crash with this new field
3/ update convert.c

Then perfparse will feed the database with a default value. This makes wo=
rk easier for
after.

> 3. Changing perfparse to scan 'nagios.cfg' to check Nagios is using the
> correct format, and exit on error if not correct.
> 4. Updating the raw data report to display this value.
> 5. Including a 'configure' definition of where to expect the Nagios
> 'etc' directory., default /usr/local/nagios/etc.

In 0.0.13 or after ?

> I also note that development time is very tight for all involved.  If
> there is anybody on this mailing list who wants to submit a patch, I
> would be very interested in hearing from them.

Not me for while: other things to do before...

Yves

>
> Regards,
>
> Ben.
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Storing the STATE from Nagios.

[Ben C. <Be...@cl...>]

Yves and others:

A request to store the plugin state has been requested, the macro name 
is: $SERVICESTATE$, from http://nagios.sourceforge.net/docs/1_0/macros.html

This is probably an oversite not to store this from version 0.01 :)

For some time in the near future, suggest:

1. Changing perfparse to expect this macro.
2. Adding a field to the raw data table to store this value.
3. Changing perfparse to scan 'nagios.cfg' to check Nagios is using the 
correct format, and exit on error if not correct.
4. Updating the raw data report to display this value.
5. Including a 'configure' definition of where to expect the Nagios 
'etc' directory., default /usr/local/nagios/etc.

I also note that development time is very tight for all involved.  If 
there is anybody on this mailing list who wants to submit a patch, I 
would be very interested in hearing from them.

Regards,

Ben.

[Perfparse-devel] hostperf.log ?

[Yves M. <yme...@li...>]

Hi !

I have 2 files called serviceperf.log and hostperf.log.
Perfparse eats what nagios feeds through serviceperf.log.
What about hostperf.log ? It contains lines like this :
1088556490    host1   PING OK - Packet loss =3D 0%, RTA =3D 0.00 ms

Perfparse seems not to be able to read it. Do you think it would be a goo=
d feature to
delete it the same way it deletes serviceperf.log when --delete is enable=
d ? Or should
we remove it another way ?
Of course, this would be optionnal, and (un)set in the cfg file.

Yves


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

Re: [Perfparse-devel] Re: perfparse-0.0.11ym1 live

[Yves M. <yme...@li...>]

> Yves,
>
> Can you confirm the correct option to use in the configure to select th=
e
> correct version of glib?
>
> I am using --with-glib12=3D/usr/bin which works with me, replying:
>
> *****************************************************
> Configuration options:
>
> ....
> Using glib1.2:                 1.2.10
> *****************************************************

For glib1.2 users, assuming that your glib-config binary is in /usr/bin, =
I confirm this
is the way to do it.

For those who have glib2, please use glib2 (ignore --with-glib12): we pro=
gram with
glib2.0 API and backport to glib1.2 for those who cannot use glib2.0. We =
do not try to
have the glib1.2 backport very performant, so glib2 is the best choice.

Your output will be:
*****************************************************
Configuration options:

....
Using glib2.0:                 2.4.2
*****************************************************

Yves
--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -

[Perfparse-devel] Re: perfparse-0.0.11ym1 live

[Ben C. <Be...@cl...>]

Yves,

Can you confirm the correct option to use in the configure to select the 
correct version of glib?

I am using --with-glib12=/usr/bin which works with me, replying:

*****************************************************
Configuration options:

....
Using glib1.2:                 1.2.10
*****************************************************

Can you also post the reply to the developers news group so that Garry 
can include in his documentation?

Ben