You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(19) |
Dec
(72) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(35) |
Feb
(36) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Ben C. <bcl...@pe...> - 2005-01-17 13:52:59
|
Yves, I have not applied the patch, but the contents looks excellent. I will release two versions this evening :) Ben Yves wrote: >>The version with PostgreSQL. There is a problem. Friedrich has >>adjusted the Makefile to allow compilation on his machine. When I 'make >>configure' these changes will be deleted. I need to get these changes >>into the configure.ac and various Makefile.am files. For this I need >>your help :) > > > I had problem because I insisted on using patch with -p1 instead of -p0 parameter :) > > Attached : a patch for all Makefile.am and configure.ac. > Use patch -p1 > Apply it against 0.104.8 (and probably 0.104.9) > > >>After this, I can release the PostgreSQL version. My belief is that >>users not selecting PostgreSQL will get the same product. Therefore a >>joint release is safe. When the configure is altered. As you say, this >>will be 0.105.1. >> >>With this need a method of selecting database: >> >>./configure --mysql (default) >>./configure --psql >>./configure --no_sql > > > This already exists (recent change : check the ChangeLog) > ./configure --help | grep postgresql > > > >>Yves, would you have time to make the required adjustments to the >>configuration? > > > Check the patch. > Some minor changes on most Makefile.am files. Major changes on cgi/Makefile.am because > CGI_INCLUDES and CGI_LIBS should remain out of the if block. > > Yves -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Yves <yme...@pe...> - 2005-01-17 12:05:44
|
> The version with PostgreSQL. There is a problem. Friedrich has > adjusted the Makefile to allow compilation on his machine. When I 'mak= e > configure' these changes will be deleted. I need to get these changes > into the configure.ac and various Makefile.am files. For this I need > your help :) I had problem because I insisted on using patch with -p1 instead of -p0 p= arameter :) Attached : a patch for all Makefile.am and configure.ac. Use patch -p1 Apply it against 0.104.8 (and probably 0.104.9) > After this, I can release the PostgreSQL version. My belief is that > users not selecting PostgreSQL will get the same product. Therefore a > joint release is safe. When the configure is altered. As you say, thi= s > will be 0.105.1. > > With this need a method of selecting database: > > ./configure --mysql (default) > ./configure --psql > ./configure --no_sql This already exists (recent change : check the ChangeLog) ./configure --help | grep postgresql > Yves, would you have time to make the required adjustments to the > configuration? Check the patch. Some minor changes on most Makefile.am files. Major changes on cgi/Makefi= le.am because CGI_INCLUDES and CGI_LIBS should remain out of the if block. 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <bcl...@pe...> - 2005-01-17 11:55:42
|
Yves, You share my thoughts about the release. 0.104.9 will be without PostgreSQL. Released this evening, about 2000 GMT. The version with PostgreSQL. There is a problem. Friedrich has adjusted the Makefile to allow compilation on his machine. When I 'make configure' these changes will be deleted. I need to get these changes into the configure.ac and various Makefile.am files. For this I need your help :) After this, I can release the PostgreSQL version. My belief is that users not selecting PostgreSQL will get the same product. Therefore a joint release is safe. When the configure is altered. As you say, this will be 0.105.1. With this need a method of selecting database: ./configure --mysql (default) ./configure --psql ./configure --no_sql With documentation. ???? Yves, would you have time to make the required adjustments to the configuration? Regards, Ben. Yves wrote: > Hi ! > > I have not tried the patch yet, and I have no postgresql to test. > Ben, I suggest that you release 0.104.9 without postgresql as soon as possible. 0.104.9 > should be the latest version without postgresql support. > At the same time, release 0.105.1 with postgresql support. > Send only one mail for the release of 0.104.9 and 0.105.1 > > Users should naturally try the "latest" version 0.105.1 with or without using the > postgresql support feature. If there is any serious problem with 0.105.1, we can tell > users to downgrade to 0.104.9 that is more stable than 0.104.8 and ask them to wait for > a more stable 0.105.2. > > Friedrich, I don't know who will support the postgresql feature at the beginning. Will > you help users and fix bugs at the beginning ? When postgresql support becomes more > popular, other will help you to help users and fix bugs. > > Ben, I will not have time to work on perfparse today and tomorrow. I don't know for > later in the week. Don't wait for me for 0.105.1. I'll only try to send comments for the > Makefile stuff :) > > Thanks for your work and for the postgresql code ! :) > > Yves > > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Yves <yme...@pe...> - 2005-01-17 11:08:17
|
Hi ! I have not tried the patch yet, and I have no postgresql to test. Ben, I suggest that you release 0.104.9 without postgresql as soon as pos= sible. 0.104.9 should be the latest version without postgresql support. At the same time, release 0.105.1 with postgresql support. Send only one mail for the release of 0.104.9 and 0.105.1 Users should naturally try the "latest" version 0.105.1 with or without u= sing the postgresql support feature. If there is any serious problem with 0.105.1,= we can tell users to downgrade to 0.104.9 that is more stable than 0.104.8 and ask th= em to wait for a more stable 0.105.2. Friedrich, I don't know who will support the postgresql feature at the be= ginning. Will you help users and fix bugs at the beginning ? When postgresql support be= comes more popular, other will help you to help users and fix bugs. Ben, I will not have time to work on perfparse today and tomorrow. I don'= t know for later in the week. Don't wait for me for 0.105.1. I'll only try to send c= omments for the Makefile stuff :) Thanks for your work and for the postgresql code ! :) 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <bcl...@pe...> - 2005-01-17 10:21:14
|
Friedrich Thanks for the returned package. I'll comment on the SQL code. Yves may comment on the Makefile alterations. I have had a brief look at the code, it looks impressive. Thanks for making the SQL a little more robust where required. Using correct ANSI SQL and correct SQL boolean values. This will help greatly the next platform used. We need to get a generic solution to iteration through a table. I see a lot of: #ifdef USE_DB_MYSQL while ((result_row = mysql_fetch_row(query_result))) { #elif defined USE_DB_POSTGRESQL numberOfRows = rows(); for (currentRow = 0; currentRow<numberOfRows; currentRow++){ #endif Maybe we can think of a way of abstracting this. Something like: #ifdef USE_DB_MYSQL #define TABLE_ITTERATE_START \ while ((result_row = mysql_fetch_row(query_result))) #else #define TABLE_ITTERATE_START \ numberOfRows = rows(); \ for (currentRow = 0; currentRow<numberOfRows; currentRow++) #endif There are a few more function that need abstracting as well. I note a test whether current row exists. I note you have a new data types, boolean and time. I'll reflect this in MySQL API. I note your comments in the tar file about VARCHAR size limits. If this is the case, please use TEXT instead. (My colleague tells me that Tom Lane of PostgreSQL says use TEXT anyware you want, it's no less efficient than VARCHAR yet having none of it's limits :) I am not sure about releasing with the next version, since this will be today. But if Yves is okay with it, I am all for releasing next versions. It will be a great addition to the application. There is also the boring bit: Documents. You may want to look at the accessible documentation and change/add anything relevant. I am very impressed with the work, look forward to it being part of the project. Regards, Ben. Priewasser, Friedrich wrote: > Hello, > > I have created the PostgreSQL storage module, as said a few weeks > ago. It already works on my system (including web frontend) - after makeing some changes to the makefiles by hand. > > > Description of the files in the uploaded package: > > Makefiles.diff: Changes to Makefiles > Changes.diff: Other changes > New: New files > perfparse_notes.txt: A few notes and problems I had > > > Please let me know what you think about > > Regards, > Friedrich > > -- > Friedrich Priewasser > Software Engineer > Fabalabs Software GmbH > Honauerstraße 4 > A-4020 Linz > e-mail: mailto:fri...@fa... > http://www.fabalabs.org > > > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Priewasser, F. <Fri...@fa...> - 2005-01-17 08:26:17
|
Hello, I have created the PostgreSQL storage module, as said a few weeks=20 ago. It already works on my system (including web frontend) - after = makeing some changes to the makefiles by hand. Description of the files in the uploaded package: Makefiles.diff: Changes to Makefiles Changes.diff: Other changes New: New files perfparse_notes.txt: A few notes and problems I had Please let me know what you think about Regards, Friedrich -- Friedrich Priewasser Software Engineer Fabalabs Software GmbH Honauerstra=DFe 4 A-4020 Linz e-mail: mailto:fri...@fa... http://www.fabalabs.org |
From: Ben C. <bcl...@pe...> - 2005-01-14 09:39:53
|
Massimiliano, Sorry for late reply. We would all be very interested in looking into a working Oracle storage. You might look into to the job of conversion of the tables in 'scripts' in latest version. This will give you some idea of the job. I'll look into getting some documentation. We also have Friedrich Priewasser, (cc on this email), who is working on PostgeSQL conversion. I think you two may keep in touch on this mailing group 'perfparse-devel-int' :) I passed Friedrick the following information as a starting point. Please enjoy, and tell us how you get along. Remember, there are lots of us who can give you advise :) Sorry I cannot give more time now. If there is anything I can think of, I will email in future. Regards, Ben. :) -------------------------------------- Email I sent to Friedrich, edit for latest changes: Priewasser, I have been talking to my partner Yves and we believe the best way to convert the product is as follows: 1. Convert the database schema: scripts/postgresql_create.sql scripts/postgresql_delete.sql Try to keep to ANSI-SQL. Eg, use BOOL, TRUE and FALSE which MySQL does not support. Rather than copying MySQL including it's short fallings :) This stage will give you a good idea of the challange to complete the work. 2. Two bits of work here, storage module and DBMS library. (i) Copy scripts/storage_mysql.* to scripts/storage_postgresql.* Edit where required. Keep the .h the same in all cases. (ii) Copy directory libpp_mysql to libpp_postgresql. Edit all parts, starting with dbms.c. Please keep .h files the same. 3. The non-graph CGI code. In the CGI code, check the SQL commands and replace where needed using syntax similar to: #ifdef MYSQL "SELECT * WHERE boolean_field = 1" #elseif POSTGRESQL "SELECT * WHERE boolean_field = TRUE" #endif These definitions do not work yet. If you continue this work, these will be added. 4. The graph module. Yves is re-writing this to access many data sources. At this stage probably best to wait until this work is a little more mature. I will be writing a MYSQL module at this point, so we can do this together. A lot has been said in response to your original email in a short time. I hope we haven't confused you. We are excited about what your work will do for our product! Please let us know your feelings and what you think of the challange. Regards, Ben & Yves. -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Yves M. <yme...@li...> - 2005-01-10 11:48:40
|
Hi all, Perfparse-0.104.7 does not compile again on my Solaris. Some parts of the fix I sent to Ben disappeared somewhere in the solar sy= stem or somewhere else. Moreover, the add of check_perfparse_version created a new compilation pr= oblem on Solaris, when linking against gd. I don't understand why it worked before= , but it works with my fix (glib at the end of the libs list). Besides this, I added a new feature for the configure script : you can sp= ecify --with-db=3Dnone. If you do that, perfparse will compile without db suppo= rt. Most features of perfparse become unavailable without db support, but you still have : - retreiving of nagios performance data - output to any place thanks to storage modules, including files (file_ou= tput module) - graph ability with gnuplot for gnuplot power users (no friendly user in= terface yet) Enjoy perfparse-0.104.7ym1 available at http://pagesperso.laposte.net/ymettier/perfparse-devel/perfparse-0.104.7/ Note : of course, nothing is documented. Bad habit of mine, I know. Sorry= :) 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <Ben...@ro...> - 2005-01-07 14:01:37
|
Sorry gues, let me catch up with my email: Tim, how do you feel about adding your scripts to the installation? If so you have a choice of 'contrib' where unsupported additions are kept, and 'scripts' where supported additions are kept. The choice is yours :) Other files: <file> contrib/check_perfparse.sh </file> I'll credit this to Yves. But I would like to rename it 'check_perfparse_dropfile.sh'. Since this is what is does. <file> contrib/perfparse_deamon.sh </file> Will be deleted. <file> config/perfparse_nagios_command.pl </file> <file> config/perfparse_nagios_pipe_command.pl </file> Yves, should we use the version which Tim has enhanced? These are currently in the 'config' directory. Should these be moved to 'scripts'? Lastly I will write a minimum program for returning whether the database version is correct or not. Which will be in nagios_plugin protocol. I'll doc this when complete. Regards, Ben. Tim Wuyts wrote: > All, > > I wrote two scripts, and posted them on the wiki: > http://wiki.perfparse.org/tiki-index.php?page=CheckingPerfparseWithNagios > > I called them: > check_perfparse.pl and check_perfparse.sh > > The first is a nagios plugin, the second should be used as an event > handler whenever the plugin reports an error. check_perfparse.sh is > based on restart_httpd.sh. > > The check_perfparse.sh script in the contrib directory is something > completely different, and was not written by me. I propose to change > the name of my check_perfparse.sh into > nagios_eventhandler_restart_perfparse.sh (I'll update the wiki > accordingly), unless someone comes up with a better name. > > As for the two .pl scripts in the config directory: > I have nothing to do with the original perfparse_nagios_command.pl and > perfparse_nagios_command_pipe.pl. I do use a slightly modified version > of the _pipe script (see below, I simply added a line to check if the > file exists AND is a pipe). > > Tim > > <FILE name="perfparse_nagios_pipe_command.pl"> > #! /usr/bin/perl -w > use strict; > my $file = shift @ARGV; > exit(0) unless (-p $file); > open FH, ">$file" or die "'$file' could not be opened for appending\n"; > print FH join("\t", @ARGV); > print FH "\n"; > close FH; > </FILE> > > On Fri, 7 Jan 2005 11:40:52 +0100 (CET), Yves <yme...@pe...> wrote: > >>>I have cc'd this to developers list in case any other contributer knows >>>of or wants to add a script to PP. >>> >>>May I check the scripts to ensure the correct author credited? >>> >>>check_perfparse.sh - Tim >>>perfparse_nagios_command.pl - Tim ? >>>perfparse_nagios_pipe_command.pl - Tim ? >> >>I wrote those 2, but they were copy/pasted from a mail. Was that Tim ? I don't remember. >>If you find the reference of that mail, I don't mind to credit only the one who sent >>that mail. Otherwise: >>Credits : Yves thanks to somebody who sent the main lines by email. >> >> >>>perfparse_daemon.sh - Yves >> >>Yes, but that one should be removed :) >> >> >>>perfparse.sh - Ben / Yves >> >>OK >> >>Ben, wait for my patch about that bug in the history command I told you about. >>However, if you cannot not wait more to release 0.104.7, do it : nobody uses the feature >>with the bug yet :) >> >>-- >>- Homepage - http://ymettier.free.fr - http://www.logicacmg.com - >>- GPG key - http://ymettier.free.fr/gpg.txt - >>- Maitretarot - http://www.nongnu.org/maitretarot/ - >>- Perfparse - http://perfparse.sf.net/ - >> >> > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Perfparse-devel-int mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfparse-devel-int > |
From: Tim W. <tim...@gm...> - 2005-01-07 11:01:38
|
All, I wrote two scripts, and posted them on the wiki: http://wiki.perfparse.org/tiki-index.php?page=CheckingPerfparseWithNagios I called them: check_perfparse.pl and check_perfparse.sh The first is a nagios plugin, the second should be used as an event handler whenever the plugin reports an error. check_perfparse.sh is based on restart_httpd.sh. The check_perfparse.sh script in the contrib directory is something completely different, and was not written by me. I propose to change the name of my check_perfparse.sh into nagios_eventhandler_restart_perfparse.sh (I'll update the wiki accordingly), unless someone comes up with a better name. As for the two .pl scripts in the config directory: I have nothing to do with the original perfparse_nagios_command.pl and perfparse_nagios_command_pipe.pl. I do use a slightly modified version of the _pipe script (see below, I simply added a line to check if the file exists AND is a pipe). Tim <FILE name="perfparse_nagios_pipe_command.pl"> #! /usr/bin/perl -w use strict; my $file = shift @ARGV; exit(0) unless (-p $file); open FH, ">$file" or die "'$file' could not be opened for appending\n"; print FH join("\t", @ARGV); print FH "\n"; close FH; </FILE> On Fri, 7 Jan 2005 11:40:52 +0100 (CET), Yves <yme...@pe...> wrote: > > > I have cc'd this to developers list in case any other contributer knows > > of or wants to add a script to PP. > > > > May I check the scripts to ensure the correct author credited? > > > > check_perfparse.sh - Tim > > perfparse_nagios_command.pl - Tim ? > > perfparse_nagios_pipe_command.pl - Tim ? > > I wrote those 2, but they were copy/pasted from a mail. Was that Tim ? I don't remember. > If you find the reference of that mail, I don't mind to credit only the one who sent > that mail. Otherwise: > Credits : Yves thanks to somebody who sent the main lines by email. > > > perfparse_daemon.sh - Yves > > Yes, but that one should be removed :) > > > perfparse.sh - Ben / Yves > > OK > > Ben, wait for my patch about that bug in the history command I told you about. > However, if you cannot not wait more to release 0.104.7, do it : nobody uses the feature > with the bug yet :) > > -- > - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - > - GPG key - http://ymettier.free.fr/gpg.txt - > - Maitretarot - http://www.nongnu.org/maitretarot/ - > - Perfparse - http://perfparse.sf.net/ - > > |
From: Yves <yme...@pe...> - 2005-01-07 10:40:56
|
> I have cc'd this to developers list in case any other contributer knows > of or wants to add a script to PP. > > May I check the scripts to ensure the correct author credited? > > check_perfparse.sh - Tim > perfparse_nagios_command.pl - Tim ? > perfparse_nagios_pipe_command.pl - Tim ? I wrote those 2, but they were copy/pasted from a mail. Was that Tim ? I = don't remember. If you find the reference of that mail, I don't mind to credit only the o= ne who sent that mail. Otherwise: Credits : Yves thanks to somebody who sent the main lines by email. > perfparse_daemon.sh - Yves Yes, but that one should be removed :) > perfparse.sh - Ben / Yves OK Ben, wait for my patch about that bug in the history command I told you a= bout. However, if you cannot not wait more to release 0.104.7, do it : nobody u= ses the feature with the bug yet :) --=20 - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - - GPG key - http://ymettier.free.fr/gpg.txt - - Maitretarot - http://www.nongnu.org/maitretarot/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <bcl...@pe...> - 2005-01-07 10:34:37
|
I have cc'd this to developers list in case any other contributer knows of or wants to add a script to PP. May I check the scripts to ensure the correct author credited? check_perfparse.sh - Tim perfparse_nagios_command.pl - Tim ? perfparse_nagios_pipe_command.pl - Tim ? perfparse_daemon.sh - Yves perfparse.sh - Ben / Yves Tim, I don't have any other scripts in the distribution currently. Is it one of these which is based on restart-httpd? Are we missing any? Regards, Ben Tim Wuyts wrote: > Ben, > > to be honest, I simply adapted this script from the Nagios > documentation to handle the perfparse daemon instead of apache. It's > not a lot more than search/replace ;) > I don't mind you adding it, but credit should not go to me alone, it > should be added that it was based on the restart-httpd script as found > in the Event Handlers section of the Nagios 1.0 doc. > > The perl script is a different matter, I don't mind if it's added there. > > Tim. > > On Fri, 07 Jan 2005 09:32:21 +0000, Ben Clewett > <Ben...@ro...> wrote: > >>Tim, >> >>By the way, >> >>May I add this to the top of your check_perfparse.sh script: >> >>######################################################################### >># Check Perfparse Nagios Plugin >># Copyright (c) 2004 Tim Wuyts <tim...@gm...> >>######################################################################### >># >># License: >># >># This program is free software; you can redistribute it and/or modify >># it under the terms of the GNU General Public License as published by >># the Free Software Foundation; either version 2 of the License, or >># (at your option) any later version. >># >># This program is distributed in the hope that it will be useful, >># but WITHOUT ANY WARRANTY; without even the implied warranty of >># MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >># GNU General Public License for more details. >># >># You should have received a copy of the GNU General Public License >># along with this program; if not, write to the Free Software >># Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. >># >>######################################################################### >> >>?? >> >>Ben >> >> >>Tim Wuyts wrote: >> >> >>>Ben, Yves, >>> >>>Sorry for the late answer, I've been enjoying a few days with my wife & kids >>>and no computers ;) >>> >>>I'm not sure why you want to check: If the module fails to load because of a >>>wrong version, the check_perfparse will fail (i.e return CRITICAL) as well >>>after the set threshold, since no data will be written to the database. >>> >>>It is not a lot of work to get the current version from the DB and check it >>>against the 'expected' value, the main problem here is where to get the >>>'expected' value from. In perfparse, this is hardcoded (in >>>libpp_mysql/common.h). I could hardcode it in the script, but then >>>1. you will need to remind yourself to update the script as well as common.h >>>whenever the version changes. >>>2. we will need to make sure that the script gets updated during 'make >>>install'. >>>But IMHO, I don't think this is a good idea. >>> >>>BTW, I have no idea if anyone actually uses this :) >>> >>>Tim >>> >>>PS: please use my gmail address for future communications, Thx. >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Ben Clewett [mailto:bcl...@pe...] >>>>Sent: 30 December 2004 13:00 >>>>To: Yves Mettier; Tim Wuyts >>>>Subject: **SPAM** **SPAM BAYESIAN_PLUGIN BODY** Re: pp-0.104.5 ? >>>>Importance: Low >>>> >>>>I'll ask Tim about this, he is 'cc' on this email. >>>> >>>>A summary to Tim: >>>> >>>>A problem exists when database version changes. The parser >>>>will exit in failure. Users may loose data. We are >>>>suggesting that you may wish to check the version of the SQL >>>>in your check_perfparse plugin. >>>> >>>>Look at code libpp_mysql/db_macro_actions.c line ~140 >>>>function 'db_version_error'. >>>> >>>>Can you replicate this in your plugin and return ERROR ? >>>> >>>>Do you want to add this plugin to the standard release ? >>>> >>>> >>>>Yves, >>>> >>>>I will have a look at the code and alter >>>>$prefix/var/storage_modules.status with the line: >>>> >>>>mysql:disable >>>> >>>>If the database is wrong. Do you have any nice code for >>>>setting these values? Or a sample I can copy? >>>> >>>>Ben >>>> >>>> >>>> >>>> >>>> >>>> >>>>Yves Mettier wrote: >>>> >>>> >>>> >>>>>>Yves, >>>>>> >>>>>>What about the check_perfparse plugin used for pipe users? >>>> >>>>Can this >>>> >>>> >>>>>>execute a check against the mysql_storage module, if that >>>> >>>>is being used? >>>> >>>> >>>>>Not as is. >>>>>Ask Tim if he as something better than check_perfparse :) >>>>> >>>>>There is something that you can do with the >>>> >>>>$prefix/var/storage_modules.status file (in >>>> >>>> >>>>>0.104.5 only) : a line with >>>>>- mysql:enabled >>>>>means that mysql is working >>>>>- mysql:disable >>>>>means that mysql module has a problem >>>>>- nothing >>>>>means that mysql module was not loaded. >>>>> >>>>> >>>>> >>>>> >>>>>>Otherwise I can just post a warning to the users. >>>>> >>>>> >>>>>Do it. >>>>>Who uses check_perfparse ? :) >>>>>Same as the mail : who uses the standard error detection >>>> >>>>mechanisms ? >>>> >>>> >>>>>>As soon as they run the CGI, they will get this error and >>>> >>>>see what is >>>> >>>> >>>>>>wrong. We can hope this is not too soon... >>>>> >>>>> >>>>>The test also exists in the CGI, so they can see it soon. >>>>> >>>>>Yves >>>>> >>>> >>>> >>>>-- >>>>Ben Clewett bcl...@pe... >>>>PerfParse http://www.perfparse.org >>>>PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php >>>> >>> >>> >> > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Ben C. <Ben...@ro...> - 2005-01-04 15:15:11
|
Yves, I want to settle this before the next release. Which is waiting for the 'make distcheck'... We cannot put the nagios lock file into the perfparse.cfg because this ties in the product with a version of Nagios which may change. I can understand this. I do not entirely agree that we are just developers. We are also packagers until somebody offers to build and maintain an RPM (or similar). This script is an essential wrapper if you with to use the 'cron' method. If we use it, we support it. Or I support it :) The script is based on a .in file, therefore a directory with a Makefile. This will be the new 'scripts' directory. The only problem we have is the definition of the nagios.lock. I will set it to the likely default: /usr/local/nagios/var/nagios.lock A sys admin will see this I hope and edit it accordingly. I am worried about removing options from the perfparse.cfg if they are at default. These files often serve as an alternate manual, self explaining what options are available. By removing most options, I don't think we serve the users interests at best. There is the option used by a lot of modern systems where all options are commented out, but shown as default in the comments: (Eg, Samba) # Option for setting foo. Default = "bar" # foo = "bar" The user can see the default, and edit it if they want to change it by uncommenting. Removal of obsolete entries is unfortunate. This does not occur often. After version 1.0.0 I hope not at all if possible. Maybe this is not so important? Ben Yves wrote: >>Mail pour yves >>============== >> >>Yves, >> >>I can read the nagios.cfg file to obtain the location of nagios.pid. I >>have a problem that none of the config variables tell me where this file >>is. I cannot assume that PP is installed into the Nagios directory >>structure. > > > You have to use a variable to write the file name. > Ask yourself what filename is best : nagios config file or nagios pid file ? :) > > >>I think this was why this was written into the perfparse.cfg. > > > No : perfparse used to use the pid of nagios. So it had to be specified into perfparse.cfg. > Now, perfparsed and perfparse-log2* don't use it, so it has nothing to do with > perfparse.cfg. > > >>The reason I didn't notice the demise of this method was that my >>perfparse.cfg is old, I have not copied over the example for quite some >>time. I thank the new user for finding this. > > > If you want to support that script, I tell you again, update your perfparse.cfg and your > perfparse.sh script at every new version of perfparse. > > >>Personally I would suggest just adding this option into perfparse.cfg >>and an entry into config_file.c to match this so that every option is >>accounted for. > > > I would not do it. If that feature is broken in nagios (it used to be in nagios-2.0), it > would become a bug of perfparse too. If that feature changes or is removed, it would > become a bug of perfparse. Don't depend on nagios too much : perfparse is not a nagios > extension but a project on its own :) > Just put it in the script, and if that feature disappear, changes or is broken, users > can easily change the script with no impact on perfparse binaries. > This is also why I think that perfparse.sh should not be included in perfparse. It is > the role of the admins to provide that script, not the role of the developers. > > And because it exists and because you want to maintain it, keep it. Some users probably > use it too. > > > > >>I will create the new scripts directory with the database creation >>scripts as well as perfparse.sh. I'll edit the documentation where I >>can find it. I hope I do not miss any! > > > Also check perfparse.cfg.example. > I suggest that you remove all options that are OK as default values (check config_file.c) > Only keep the options when perfparse cannot work if they are not edited (like the > directory where modules are, like the mysql login parameters...) > Remove the others : users can do perfparsed --show_config to have all :) > If you remove them, you will have less obsolete entries in the future when you > add/remove/change options of the config :) > > Yves > |
From: Yves <yme...@pe...> - 2005-01-04 14:44:26
|
> Mail pour yves > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Yves, > > I can read the nagios.cfg file to obtain the location of nagios.pid. I > have a problem that none of the config variables tell me where this fil= e > is. I cannot assume that PP is installed into the Nagios directory > structure. You have to use a variable to write the file name. Ask yourself what filename is best : nagios config file or nagios pid fil= e ? :) > I think this was why this was written into the perfparse.cfg. No : perfparse used to use the pid of nagios. So it had to be specified i= nto perfparse.cfg. Now, perfparsed and perfparse-log2* don't use it, so it has nothing to do= with perfparse.cfg. > > The reason I didn't notice the demise of this method was that my > perfparse.cfg is old, I have not copied over the example for quite some > time. I thank the new user for finding this. If you want to support that script, I tell you again, update your perfpar= se.cfg and your perfparse.sh script at every new version of perfparse. > > Personally I would suggest just adding this option into perfparse.cfg > and an entry into config_file.c to match this so that every option is > accounted for. I would not do it. If that feature is broken in nagios (it used to be in = nagios-2.0), it would become a bug of perfparse too. If that feature changes or is remove= d, it would become a bug of perfparse. Don't depend on nagios too much : perfparse is= not a nagios extension but a project on its own :) Just put it in the script, and if that feature disappear, changes or is b= roken, users can easily change the script with no impact on perfparse binaries. This is also why I think that perfparse.sh should not be included in perf= parse. It is the role of the admins to provide that script, not the role of the develo= pers. And because it exists and because you want to maintain it, keep it. Some = users probably use it too. > > I will create the new scripts directory with the database creation > scripts as well as perfparse.sh. I'll edit the documentation where I > can find it. I hope I do not miss any! Also check perfparse.cfg.example. I suggest that you remove all options that are OK as default values (chec= k config_file.c) Only keep the options when perfparse cannot work if they are not edited (= like the directory where modules are, like the mysql login parameters...) Remove the others : users can do perfparsed --show_config to have all :) If you remove them, you will have less obsolete entries in the future whe= n you add/remove/change options of the config :) 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <bcl...@pe...> - 2005-01-04 14:13:21
|
Yves, I can read the nagios.cfg file to obtain the location of nagios.pid. I have a problem that none of the config variables tell me where this file is. I cannot assume that PP is installed into the Nagios directory structure. I think this was why this was written into the perfparse.cfg. The reason I didn't notice the demise of this method was that my perfparse.cfg is old, I have not copied over the example for quite some time. I thank the new user for finding this. Personally I would suggest just adding this option into perfparse.cfg and an entry into config_file.c to match this so that every option is accounted for. I will create the new scripts directory with the database creation scripts as well as perfparse.sh. I'll edit the documentation where I can find it. I hope I do not miss any! Ben Yves wrote: >>Just another comment: >> >>Reinstating the perfparse.sh does not need any c code. This reads the >>perfparse.cfg file directly. All that is needed is the nagios.lock >>definition returned to this file :) > > > A suggestion : don't mix the config of perfparse and the config of nagios :) > > An admin would write a script to find nagios.lock directly in nagios config files, have > a env variable or another mechanism, but not put that in perfparse.cfg. > > As an admin, I even think that is it not the job of perfparse developers to provide > those scripts, but the job of packagers and companies that sell support. But well, we > have it and users enjoy it, so keep it in perfparse :) > > Yves > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Yves <yme...@pe...> - 2005-01-04 13:45:59
|
> Just another comment: > > Reinstating the perfparse.sh does not need any c code. This reads the > perfparse.cfg file directly. All that is needed is the nagios.lock > definition returned to this file :) A suggestion : don't mix the config of perfparse and the config of nagios= :) An admin would write a script to find nagios.lock directly in nagios conf= ig files, have a env variable or another mechanism, but not put that in perfparse.cfg. As an admin, I even think that is it not the job of perfparse developers = to provide those scripts, but the job of packagers and companies that sell support. = But well, we have it and users enjoy it, so keep it in perfparse :) 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Yves <yme...@pe...> - 2005-01-04 13:41:09
|
> Yves, > > I kept the original thread in the 'users' mailing list, my thinking > being that they are the ones who uss this, and will therefore know. I > hope we get some response from them about who still uses this. We should talk here on perfparse-devel-int and post our conclusion on per= fparse-users and ask for their opinion. If we flood perfparse-users with that thread, = nobody will read our last mail with the conclusion, and nobody will say who still use= s it. This is why I moved to perfparse-devel-int. > I my self use the perfparse.sh script on a live server. I do a clean > parse every hour, which is the way I want to run that server. I have > not upgraded this one for a while, so was unaware of the nagios.lock > being taken out of the config. Do you remember which version this was > removed? I remember now that there are 2 things. - nagios reboot with perfparse : in 0.100.7 and removed in 0.101 ? Check = the ChangeLog :) - nagios reboot thanks to the script : new feature of the script since 0.= 101 ? I forgot that feature of the script. So yes, there is still a nagios lock. But it should be removed of the per= fparse config. This is the nagios config only, and a parameter of perfparse.sh script. > Therefore I would prefer it is supported as-is. It's a nice ability if > people want it, although there may be better methods. I think it's the best method. Provide the tool, and administrators provide script for running the tool = the way they want. And we graciously give such a script :) Do you want to support it ? if yes, I see no problem, but you should upgr= ade that script at every new version. When you install a new perfparse version, you get a perfparse.sh.example = script. So the perfparse.sh script you have is still the old one, that continues to work= for you. Maybe users have a different script. Be sure that you are running the latest on= e :) > I also comment on the 'contrib' directory. This contains the > create/drops scripts for the database. Which I chose because that's > where Nagios puts them, so users may find them more easily. These are > supported. Maybe these need another directory? I agree with you. I suggest a new directory, where you put the db create/drop scripts, *and= perfparse.sh* script. In 0.104.5, "make install" installs perfparse.sh.example". I suggest that= newer versions don't install it (like the db create/drop scripts). Users can find it in the scripts/ directory and install it themselves. Fo= r packaged solutions, this is the job of packagers to do it, not to do it, or to pro= vide their own scripts in their packages. > I agree that the perfparse_deamon.sh should go. I agree with you. Do you want that I do all of that and make a 0.104.5ym1 release or do you= prefer to do it yourself ? 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <Ben...@ro...> - 2005-01-04 12:16:23
|
Just another comment: Reinstating the perfparse.sh does not need any c code. This reads the perfparse.cfg file directly. All that is needed is the nagios.lock definition returned to this file :) Ben Ben Clewett wrote: > Yves, > > I kept the original thread in the 'users' mailing list, my thinking > being that they are the ones who uss this, and will therefore know. I > hope we get some response from them about who still uses this. > > I my self use the perfparse.sh script on a live server. I do a clean > parse every hour, which is the way I want to run that server. I have > not upgraded this one for a while, so was unaware of the nagios.lock > being taken out of the config. Do you remember which version this was > removed? > > Therefore I would prefer it is supported as-is. It's a nice ability if > people want it, although there may be better methods. > > I also comment on the 'contrib' directory. This contains the > create/drops scripts for the database. Which I chose because that's > where Nagios puts them, so users may find them more easily. These are > supported. Maybe these need another directory? > > I agree that the perfparse_deamon.sh should go. > > Ben > > > Yves wrote: > >> Hi ! >> >> There are 2 scripts perfparse.sh and perfparse_daemon.sh in the >> perfparse project. >> Are they working ? Are they supported ? Are they obsolete ? Should >> they be removed ? >> >> perfparse_daemon.sh >> =================== >> It's in the contrib/ directory. I consider that everything in contrib/ >> is unsupported. >> We can update things in contrib/ ourselves, but it's like a place to >> put things that we >> don't use and cannot support easily. >> >> perfparse_daemon.sh was made before perfparsed. Now, we have >> perfparsed that does better >> work than perfparse_daemon.sh and perfparse-log2mysql combined. >> I think that perfparse_daemon.sh should be removed, even if it seems >> to work and to be >> up to date :) >> It's better to force users who are running perfparse_daemon.sh to use >> perfparsed. Of >> course, they can keep their script if they want. >> >> perfparse.sh >> ============ >> >> This script contains a reference to nagios lock. For that reason, I >> consider it as >> obsolete. But it is in perfparse/ directory so we have to consider it >> as supported. A >> decision has to be taken here : remove it or update it quick ? :) >> >> In the doc, perfparse.sh is used in the crontab, to call perfparse-log2* >> We now have perfparsed, but perfparsed does not do exactly the same job. >> Users who are running perfparse.sh with a "* * * * *" scheduling >> should use perfparsed. >> Users who are running perfparse.sh every 10 minutes or every hour or >> every day cannot >> use perfparsed for that. Those users can run perfparse-log2* with the >> -c option >> (configuration file). Should we provide a script that just does it ? >> Decision to be taken : >> - do we update perfparse.sh and support it ? >> - do we remove perfparse.sh from perfparse ? >> - do we update perfparse.sh and move it to contrib/ (in order to say >> that we don't >> support it) ? >> >> Your opinion... ? >> >> Yves > > > |
From: Ben C. <bcl...@pe...> - 2005-01-04 12:02:44
|
Yves, I kept the original thread in the 'users' mailing list, my thinking being that they are the ones who uss this, and will therefore know. I hope we get some response from them about who still uses this. I my self use the perfparse.sh script on a live server. I do a clean parse every hour, which is the way I want to run that server. I have not upgraded this one for a while, so was unaware of the nagios.lock being taken out of the config. Do you remember which version this was removed? Therefore I would prefer it is supported as-is. It's a nice ability if people want it, although there may be better methods. I also comment on the 'contrib' directory. This contains the create/drops scripts for the database. Which I chose because that's where Nagios puts them, so users may find them more easily. These are supported. Maybe these need another directory? I agree that the perfparse_deamon.sh should go. Ben Yves wrote: > Hi ! > > There are 2 scripts perfparse.sh and perfparse_daemon.sh in the perfparse project. > Are they working ? Are they supported ? Are they obsolete ? Should they be removed ? > > perfparse_daemon.sh > =================== > It's in the contrib/ directory. I consider that everything in contrib/ is unsupported. > We can update things in contrib/ ourselves, but it's like a place to put things that we > don't use and cannot support easily. > > perfparse_daemon.sh was made before perfparsed. Now, we have perfparsed that does better > work than perfparse_daemon.sh and perfparse-log2mysql combined. > I think that perfparse_daemon.sh should be removed, even if it seems to work and to be > up to date :) > It's better to force users who are running perfparse_daemon.sh to use perfparsed. Of > course, they can keep their script if they want. > > perfparse.sh > ============ > > This script contains a reference to nagios lock. For that reason, I consider it as > obsolete. But it is in perfparse/ directory so we have to consider it as supported. A > decision has to be taken here : remove it or update it quick ? :) > > In the doc, perfparse.sh is used in the crontab, to call perfparse-log2* > We now have perfparsed, but perfparsed does not do exactly the same job. > Users who are running perfparse.sh with a "* * * * *" scheduling should use perfparsed. > Users who are running perfparse.sh every 10 minutes or every hour or every day cannot > use perfparsed for that. Those users can run perfparse-log2* with the -c option > (configuration file). Should we provide a script that just does it ? > Decision to be taken : > - do we update perfparse.sh and support it ? > - do we remove perfparse.sh from perfparse ? > - do we update perfparse.sh and move it to contrib/ (in order to say that we don't > support it) ? > > Your opinion... ? > > Yves -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Yves <yme...@pe...> - 2005-01-04 10:44:42
|
Hi ! There are 2 scripts perfparse.sh and perfparse_daemon.sh in the perfparse= project. Are they working ? Are they supported ? Are they obsolete ? Should they b= e removed ? perfparse_daemon.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It's in the contrib/ directory. I consider that everything in contrib/ is= unsupported. We can update things in contrib/ ourselves, but it's like a place to put = things that we don't use and cannot support easily. perfparse_daemon.sh was made before perfparsed. Now, we have perfparsed t= hat does better work than perfparse_daemon.sh and perfparse-log2mysql combined. I think that perfparse_daemon.sh should be removed, even if it seems to w= ork and to be up to date :) It's better to force users who are running perfparse_daemon.sh to use per= fparsed. Of course, they can keep their script if they want. perfparse.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This script contains a reference to nagios lock. For that reason, I consi= der it as obsolete. But it is in perfparse/ directory so we have to consider it as = supported. A decision has to be taken here : remove it or update it quick ? :) In the doc, perfparse.sh is used in the crontab, to call perfparse-log2* We now have perfparsed, but perfparsed does not do exactly the same job. Users who are running perfparse.sh with a "* * * * *" scheduling should u= se perfparsed. Users who are running perfparse.sh every 10 minutes or every hour or ever= y day cannot use perfparsed for that. Those users can run perfparse-log2* with the -c = option (configuration file). Should we provide a script that just does it ? Decision to be taken : - do we update perfparse.sh and support it ? - do we remove perfparse.sh from perfparse ? - do we update perfparse.sh and move it to contrib/ (in order to say that= we don't support it) ? Your opinion... ? 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <bcl...@pe...> - 2004-12-30 12:43:51
|
Priewasser Sorry for not replying sooner. There will be a great deal of interest in your work. I am sure there are many users who will want to use this version without delay. Please beware of changed. There are a few. Look at the Change Log in each version. Subscribe to the perfparse-devel-int mailing list, any changes should be posted there. (This email is 'cc' to this list.) Change so far: - The function 'addField' now returns 'int'. It used to return 'void'. - On the host, service and metric tables I have added a second unique key, which will be used in later versions of code. Called host_id, service_id and metric_id. Change to code in storage_mysql to correctly populate this field. If you want to share any information, please create a document on wiki.perfparse.org. This can be used as a URL in any work you complete. For the time being, please don't touch the 'summary' tables. These are being changed at the moment. I don't want you to waist any time! Please let us know if there is anything you need from us, we are all here to help! Regards, Ben Priewasser, Friedrich wrote: > Hi, > > Thanks for your quick response and for the tips. I will try to build the PostgreSQL storage the way you described (starting in about a week or two). > At first sight I think there schould be no "big" problem converting the storage from MySQL to PostgreSQL. > > Regards, > Friedrich > > > >>Priewasser, >> >>I have been talking to my partner Yves and we believe the best way to >>convert the product is as follows: >> >> >>1. Convert the database schema: >> >> contrib/postgresql_create.sql >> contrib/postgresql_delete.sql >> >>Try to keep to ANSI-SQL. Eg, use BOOL, TRUE and FALSE which MySQL does >>not support. Rather than copying MySQL including it's short fallings :) >> >>This stage will give you a good idea of the challange to complete the work. >> >> >>2. Two bits of work here, storage module and DBMS library. >> >>(i) Copy modules/storage_mysql.* to modules/storage_postgresql.* >> >>Edit where required. Keep the .h the same in all cases. >> >>(ii) Copy directory libpp_mysql to libpp_postgresql. >> >>Edit all parts, starting with dbms.c. Please keep .h files the same. >> >> >>3. The non-graph CGI code. >> >>In the CGI code, check the SQL commands and replace where needed using >>syntax similar to: >> >>#ifdef MYSQL >> "SELECT * WHERE boolean_field = 1" >>#elseif POSTGRESQL >> "SELECT * WHERE boolean_field = TRUE" >>#endif >> >>These definitions do not work yet. If you continue this work, these >>will be added. >> >> >>4. The graph module. >> >>Yves is re-writing this to access many data sources. At this stage >>probably best to wait until this work is a little more mature. I will >>be writing a MYSQL module at this point, so we can do this together. >> >> >> >>A lot has been said in response to your original email in a short time. >> I hope we haven't confused you. We are excited about what your work >>will do for our product! >> >>Please let us know your feelings and what you think of the challange. >> >>Regards, >> >>Ben & Yves. >> > > > -- > Friedrich Priewasser > Software Engineer > Fabalabs Software GmbH > Honauerstraße 4 > A-4020 Linz > e-mail: mailto:fri...@fa... > http://www.fabalabs.org > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Ben C. <bcl...@pe...> - 2004-12-30 11:50:56
|
The attached patch against 0.104.5 should fix the locale problems. To all contributers: Please remember with all new work. If the float/double is not being displayed, use this convention! Ben Ben Clewett wrote: > Ok. > > When ever the CGI or SQL is called with floats, I will: > > setlocale(LC_NUMERIC, "POSIX"); > sprintf(sql, "INSERT data = %f", 0.17); > setlocale(LC_NUMERIC, ""); > > Since there are users battling this problem now. And this will corrupt > the database. I'll have to do this now. The summary tables will wait a > day. > > None of your work is with the CGI or SQL today? > > Ben > > > > > Yves wrote: > >>> Hi Yves, >>> >>> The problem is not with MySQL but with 'c'. The language translation >>> introduced a line of code which forces the 'format' to output floating >>> numbers in local format: >>> >>> printf("%f", 0.17) -> "0,17" >> >> >> >> OK :) >> >> >> >> >>> 1. The 'atof' is not locale safe. 0,17 -> 0.00 >> >> >> >> I suppose that strtof and strtod are not locale safe either. >> >> >>> 2. The interface to the database. DBMS expects numbers in POSIX format: >>> >>> "INSERT (1,17)" is understood as "INSERT ('1', '17')" >>> "INSERT ('1,17')" is understood as "INSERT ('1'); >>> >>> Users with this version in these countries are therefore sending corrupt >>> data to their database. Eg, 'show_load' will be storing only the >>> integer part of the numbers. THIS IS BAD! >> >> >> >> I agree :) >> >> >>> 3. The HTML CGI interface. Floating numbers are likely to be >>> corruption as above. >>> >>> >>> The hack I suggested will fix this: >>> >>> setlocale(LC_NUMERIC, "POSIX"); >>> >>> But it may be a little too blunt. >> >> >> >> Correct as a quick fix. >> >> >>> So what do we do? >>> >>> 1. Set locale to "POSIX" and loose the localized display? >> >> >> >> no :) >> >> >>> 2. Set locale to "POSIX" before any SQL, and back to "" afterwards: >>> >>> setlocale(LC_NUMERIC, "POSIX"); >>> sprintf(sql, "INSERT data = %f", 0.17); >>> setlocale(LC_NUMERIC, ""); >> >> >> >> yes, maybe this is best. >> >> >>> 3. Set the locale to "POSIX" for all the code, accept the presentation. >>> Here and here only, set back to "": >>> >>> setlocale(LC_NUMERIC, ""); >>> printf("Graph label: %f", 0.17); >>> setlocale(LC_NUMERIC, "POSIX"); >> >> >> >> Probably more to print than floats to send to the database. 2 is better. >> >> Yves > > > -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Ben C. <bcl...@pe...> - 2004-12-30 10:52:29
|
Ok. When ever the CGI or SQL is called with floats, I will: setlocale(LC_NUMERIC, "POSIX"); sprintf(sql, "INSERT data = %f", 0.17); setlocale(LC_NUMERIC, ""); Since there are users battling this problem now. And this will corrupt the database. I'll have to do this now. The summary tables will wait a day. None of your work is with the CGI or SQL today? Ben Yves wrote: >>Hi Yves, >> >>The problem is not with MySQL but with 'c'. The language translation >>introduced a line of code which forces the 'format' to output floating >>numbers in local format: >> >>printf("%f", 0.17) -> "0,17" > > > OK :) > > > > >>1. The 'atof' is not locale safe. 0,17 -> 0.00 > > > I suppose that strtof and strtod are not locale safe either. > > >>2. The interface to the database. DBMS expects numbers in POSIX format: >> >>"INSERT (1,17)" is understood as "INSERT ('1', '17')" >>"INSERT ('1,17')" is understood as "INSERT ('1'); >> >>Users with this version in these countries are therefore sending corrupt >>data to their database. Eg, 'show_load' will be storing only the >>integer part of the numbers. THIS IS BAD! > > > I agree :) > > >>3. The HTML CGI interface. Floating numbers are likely to be >>corruption as above. >> >> >>The hack I suggested will fix this: >> >>setlocale(LC_NUMERIC, "POSIX"); >> >>But it may be a little too blunt. > > > Correct as a quick fix. > > >>So what do we do? >> >>1. Set locale to "POSIX" and loose the localized display? > > > no :) > > >>2. Set locale to "POSIX" before any SQL, and back to "" afterwards: >> >>setlocale(LC_NUMERIC, "POSIX"); >>sprintf(sql, "INSERT data = %f", 0.17); >>setlocale(LC_NUMERIC, ""); > > > yes, maybe this is best. > > >>3. Set the locale to "POSIX" for all the code, accept the presentation. >> Here and here only, set back to "": >> >>setlocale(LC_NUMERIC, ""); >>printf("Graph label: %f", 0.17); >>setlocale(LC_NUMERIC, "POSIX"); > > > Probably more to print than floats to send to the database. 2 is better. > > Yves -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |
From: Yves <yme...@pe...> - 2004-12-30 10:24:52
|
> Hi Yves, > > The problem is not with MySQL but with 'c'. The language translation > introduced a line of code which forces the 'format' to output floating > numbers in local format: > > printf("%f", 0.17) -> "0,17" OK :) > 1. The 'atof' is not locale safe. 0,17 -> 0.00 I suppose that strtof and strtod are not locale safe either. > > 2. The interface to the database. DBMS expects numbers in POSIX format= : > > "INSERT (1,17)" is understood as "INSERT ('1', '17')" > "INSERT ('1,17')" is understood as "INSERT ('1'); > > Users with this version in these countries are therefore sending corrup= t > data to their database. Eg, 'show_load' will be storing only the > integer part of the numbers. THIS IS BAD! I agree :) > 3. The HTML CGI interface. Floating numbers are likely to be > corruption as above. > > > The hack I suggested will fix this: > > setlocale(LC_NUMERIC, "POSIX"); > > But it may be a little too blunt. Correct as a quick fix. > So what do we do? > > 1. Set locale to "POSIX" and loose the localized display? no :) > 2. Set locale to "POSIX" before any SQL, and back to "" afterwards: > > setlocale(LC_NUMERIC, "POSIX"); > sprintf(sql, "INSERT data =3D %f", 0.17); > setlocale(LC_NUMERIC, ""); yes, maybe this is best. > 3. Set the locale to "POSIX" for all the code, accept the presentation. > Here and here only, set back to "": > > setlocale(LC_NUMERIC, ""); > printf("Graph label: %f", 0.17); > setlocale(LC_NUMERIC, "POSIX"); Probably more to print than floats to send to the database. 2 is better. 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/ - - Perfparse - http://perfparse.sf.net/ - |
From: Ben C. <bcl...@pe...> - 2004-12-30 09:45:07
|
Hi Yves, The problem is not with MySQL but with 'c'. The language translation introduced a line of code which forces the 'format' to output floating numbers in local format: printf("%f", 0.17) -> "0,17" I can see in the code the calls to setlocale. Sample: setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); textdomain(PACKAGE); Looking at the man page: 'If locale is "", each part of the locale that should be modified is set according to the environment variables.' Therefore this code is looking at the language and causing the change in behavior of the 'printf' format. I can see this being an attractive solution for data presentation. I am sure many people would prefer the graph labels to show as '0,000' and not '0.000'. There are some problems: 1. The 'atof' is not locale safe. 0,17 -> 0.00 2. The interface to the database. DBMS expects numbers in POSIX format: "INSERT (1,17)" is understood as "INSERT ('1', '17')" "INSERT ('1,17')" is understood as "INSERT ('1'); Users with this version in these countries are therefore sending corrupt data to their database. Eg, 'show_load' will be storing only the integer part of the numbers. THIS IS BAD! 3. The HTML CGI interface. Floating numbers are likely to be corruption as above. The hack I suggested will fix this: setlocale(LC_NUMERIC, "POSIX"); But it may be a little too blunt. So what do we do? 1. Set locale to "POSIX" and loose the localized display? 2. Set locale to "POSIX" before any SQL, and back to "" afterwards: setlocale(LC_NUMERIC, "POSIX"); sprintf(sql, "INSERT data = %f", 0.17); setlocale(LC_NUMERIC, ""); 3. Set the locale to "POSIX" for all the code, accept the presentation. Here and here only, set back to "": setlocale(LC_NUMERIC, ""); printf("Graph label: %f", 0.17); setlocale(LC_NUMERIC, "POSIX"); ??? Ben Yves Mettier wrote: >>Please edit libpp_mysql/dbms.c >> >>Near the top please add: >> >>#include <locale.h> >> >>Then after line 227 in function now_connect please add: >> >>setlocale(LC_NUMERIC, "POSIX"); >> >>Now please 'make' and let us know. >> >>To other members: >> >>Would any of you know which component effects this definition? > > > Only the numeric format on localized builds of perfparse. > In reality : nearly nothing. > > I have another question : cannot you ask mysql to read your queries as POSIX instead of > localized ? Somebody knows how ? > > >>Is this fix supported by FreeBSD, SUN and others if added to the >>standard distribution? > > > It should be. We already use setlocale() in perfparsed. > > Yves -- Ben Clewett bcl...@pe... PerfParse http://www.perfparse.org PP FAQ http://wiki.perfparse.org/tiki-list_faqs.php |