Closed GoogleCodeExporter closed 8 years ago
I have no idea what could be wrong other than that your Cacti installation is
broken.
It should be replacing <path_php_binary> with the name of php (probably
/usr/bin/php) on your system.
I am 99% sure this has nothing to do with the templates or scripts.
Original comment by baron.schwartz
on 30 Nov 2008 at 1:06
Original comment by swiatek....@gmail.com
on 30 Nov 2008 at 3:04
I think I found a problem. I seems that imported templates did have "--hostname
hostname" and similar entries in "data input methods", where those should be in
form
of "--hostname <hostname>" (brackets). Input string line also did contain "--
password password", etc, but I am not sure if I did not add those when I was
trying
to figure out what was wrong. Anyway without it is using password from Script
file
(what is one usually wants).
Interesting thing is that usually when I had "import problems", then I was
getting
escaped codes like > in place of >. This time I had those missing, without any
hint, but again I have changed those templates many times, so just make sure
you
have those <> in parameters list and remove password and login/used (do not
remember
exact name of that parameter) from Data Input Methods/Input String and Data
Input
Methods/Input Fields and you should be ok if you have similar problem I had.
Thank you for those templates, they are really good.
I think you can close this ticket now.
Regards
Original comment by swiatek....@gmail.com
on 23 Dec 2008 at 10:09
I forgot to add that path_php_binary was also missing <>, and this was small
hint,
but even when replaced with exact full path /usr/bin/php (first thing I
checked) it
did not solved problem until previously mentioned entries have been
modified/removed.
Original comment by swiatek....@gmail.com
on 23 Dec 2008 at 10:11
I'm really unclear on whether you found that the problem was just the way you're
using the templates? Or is there some change that needs to be made in the code?
Original comment by baron.schwartz
on 24 Dec 2008 at 6:50
It seems that:
a) during import "<" and ">" signs haven't been imported correctly for
"<php_binary>" and parameters entries
b) parameters password and login (or whatever second name is) are not required
(in
Data Input Methods) usually as without those login/password from script file is
used
(I am not sure about this one, as those might appear during time I was fiddling
to
make those templates work)
Original comment by swiatek....@gmail.com
on 29 Dec 2008 at 8:27
The problem is that that after importing the templates the input string for the
data
input methods looks like:
path_php_binary -q path_cacti/scripts/ss_get_mysql_stats.php --host hostname
--items
c6,cb,c4,ca,c8,c7,cc,c5,c3,c9,c2 --user username --pass password
when it really should look like:
<path_php_binary> -q <path_cacti>/scripts/ss_get_mysql_stats.php --host
<hostname>
--items c6,cb,c4,ca,c8,c7,cc,c5,c3,c9,c2 --user <username> --pass <password>
Apparently the ">" and "<" entities in the template xml file don't get
converted properly.
Original comment by djacobfe...@gmail.com
on 16 Jan 2009 at 6:52
Yes, this was a problem.
Original comment by swiatek....@gmail.com
on 18 Jan 2009 at 7:13
What was the fix? I'm having the same issue.
Original comment by cvantas...@gmail.com
on 21 Jan 2009 at 8:36
To cvantassle: Please check comments 3, 6 and 7 (missing <> chars). In 3 you
will
find where those entries are missing.
Original comment by swiatek....@gmail.com
on 22 Jan 2009 at 10:03
swiatek.janusz:
The resolution is still unclear. The template xml already has > and < in the
correct places. It is just that in the tables, the brackets are missing. So
as
djacobfeuerborn mentionsm, it seems like a problem in importing the template.
What did you change to fix the problem? Changing the xml (> to ">" and < to
"<"), just causes xml parse errors.
So I tried editing the entries in the db tables themselves, but that does not
seem to
fix the problem?
Where do you make the change?
Original comment by yuji.shi...@gmail.com
on 23 Jan 2009 at 11:25
Once again swiatek.janusz: is any change required in the template code, i.e. is
this
a bug in the templates? Or is it a bug in Cacti's import routine that I can't
do
anything about, in which case you have to edit the template manually through the
Cacti user interface?
I can tell you that on 0.8.7b on CentOS I cannot reproduce this bug. So anyone
who
wants it fixed needs to give some clearer information.
Original comment by baron.schwartz
on 23 Jan 2009 at 11:37
I just tried again on CentOS 5.2 with the Cacti I installed from yum, which is
0.8.7b, and when I wipe the database clean and then go to Data Input Methods ->
X Get
MySQL Stats/InnoDB Buffer Pool Activity, I see
<path_php_binary> -q <path_cacti>/scripts/ss_get.....--pass <password>
I tried this both with the XML file from release/ and with a newly generated
template
file.
Original comment by baron.schwartz
on 23 Jan 2009 at 11:58
Yuji,
After importing templates I have changed those >/< in Cacti Console/Data Input
Methods/for every X Get MySQL Stats/..., etc
In general I have only changed Cacti templates (after importing).
It seems that it is cacti import problem, as it was working for you with
CentOS. But
version is the same, so not 100% sure...
Again, I am using cacti-0.8.7b-r2, apache-2.2.10, mysql-5.0.70-r1, php-5.2.8-r2
(upgraded regularly).
Original comment by swiatek....@gmail.com
on 23 Jan 2009 at 12:35
baron.schwartz:
I can export those templates from my Cacti and send to you if it will help.
Just let
me know. Maybe it has something to do with regional/unicode settings?
Original comment by swiatek....@gmail.com
on 23 Jan 2009 at 12:39
So, I got it working. The workaround ended up being:
- Updating the column input_string in the table data_input to have the brackets
<>
around all the appropriate strings (e.g. path_php_binary, path_cacti,
hostname...)
- deleting and re-adding my device and re-selecting the graphs. (I was missing
this
step earlier). This updates the table poller_item with the correct entries.
After that the poller started collecting normally.
So, in the end it seems to be an issue with the import of the template.
Strange that
we see the problem and you do not, Baron.
Is it possibly a web client issue? I am using MacOSX 10.5 and 10.4 / Firefox
3.0.5 on
the client side.
The server is:
redhat fedora core 9
php 5.2.6
cacti 0.8.7b
mysql-cacti-templates 1.1.1
Original comment by yuji.shi...@gmail.com
on 23 Jan 2009 at 12:42
Ah. I did not see that you could update the Data Input Method in the UI
itself. So
I did not really need to edit the cacti database as I stated in 16. So my
workaround
is overkill. In any case, editing the input methods fixes the problem.
Original comment by yuji.shi...@gmail.com
on 23 Jan 2009 at 12:51
swiatek.janusz, you are using a newer version than you originally said... but
yuji's
version is the same as mine. If you would export the template and send it to
me,
that would be great, maybe there is something different about the XML.
A possible workaround is something like this, I think:
update data_input set input_string =
replace(replace(replace(replace(replace(replace(input_string, 'path_php_binary',
'<path_php_binary>'), 'path_cacti', '<path_cacti>'), 'hostname', '<hostname>'),
'items', '<items>'), 'username', '<username>'), 'password', '<password>') where
input_string like '%ss_get_mysql_stats.php%' and input_string not like
'%<path_php_binary>%';
Back up your Cacti database first.
I'm using a CentOS virtual machine, so I'm running the web browser, etc all
within
one machine.
Original comment by baron.schwartz
on 23 Jan 2009 at 12:51
Yes, but editing in the UI is a royal pain :) Hence my whole meta-language for
defining templates... it would take a week to create a template without it (I
know
from experience)
Original comment by baron.schwartz
on 23 Jan 2009 at 12:53
Baron, i totally agree with your last comment, I tried to find why cacti would
replace the proper values from your templates before importing them, and didn't
find
why, so i came up with following SQL script to perform on the cacti database
after
completing the import. Maybe that'd be worth including in the README ?
start transaction;
update data_input set input_string = replace (input_string,
'path_php_binary','<path_php_binary>');
update data_input set input_string = replace (input_string,
'path_cacti/','<path_cacti>/');
update data_input set input_string = replace (input_string,
'hostname','<hostname>');
update data_input set input_string = replace (input_string,
'username','<username>');
update data_input set input_string = replace (input_string,
'password','<password>');
-- check check
select input_string from data_input;
-- commit;
rollback;
Original comment by ear...@gmail.com
on 3 May 2009 at 5:20
I'll put this into the FAQ.
Original comment by baron.schwartz
on 5 May 2009 at 5:18
This is in the FAQ.
Original comment by baron.schwartz
on 24 Oct 2009 at 1:30
this < and > getting lost is mostly due broken php xml module. i got my system
fixed
when i rebuilt my php 5.2.13 with newer libxml (2.2.7)
here's working system:
$ php -r '$p = xml_parser_create(); xml_parse_into_struct($p,
"<xml><path_php_binary></xml>", $vals, $index); print_r($vals);'
Array
(
[0] => Array
(
[tag] => XML
[type] => complete
[level] => 1
[value] => <path_php_binary>
)
)
and here's broken system
php -r '$p = xml_parser_create(); xml_parse_into_struct($p,
"<xml><path_php_binary></xml>", $vals, $index); print_r($vals);'
Array
(
[0] => Array
(
[tag] => XML
[type] => complete
[level] => 1
[value] => path_php_binary
)
)
Original comment by elan.ruu...@gmail.com
on 6 May 2010 at 12:54
Hi,
I have this problem on my system. I have run the script from the post <20> but
still no graphs.
I get a lot of error messages like this "sh: path_php_binary: command not
found" in poller-error.log
Any suggestions?
Thanks
Original comment by petre.gh...@gmail.com
on 28 Oct 2010 at 10:15
Petre - Quick, but DIRTY fix: Go through your config inside cacti and replace
each occurrence of "path_php_binary" with whatever "which php" command will
return (most likely "/usr/bin/php" or something similar).
Original comment by swiatek....@gmail.com
on 28 Oct 2010 at 10:24
Original issue reported on code.google.com by
swiatek....@gmail.com
on 28 Nov 2008 at 2:14