google-code-export / mysql-cacti-templates

Automatically exported from code.google.com/p/mysql-cacti-templates
GNU General Public License v2.0
1 stars 0 forks source link

sh: path_php_binary: command not found #49

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1. Copy/update php script, import template, add new graphs.
2. Wait for poller to try to get data or run cmd.php

When executed directly as php script (php ss_get_mysql_stats.php --host 
127.0.0.1:3306 --items bf) it is showing result correct result (even when 
sudo -u apache - so permissions to temp file are correct).

When running from command line using cmd.php or by cacti poller itself I 
am getting:
_date_ - CMDPHP: Poller[x] Host[x] DS[x] WARNING: Result from CMD not 
valid.  Partial Result:
sh: path_php_binary: command not found

It is not my only script (but rest I have are perl based). I have checked 
and corrected paths in data input methods - no change.

Could you please check what might be wrong?

Cacti 0.8.7b, Gentoo linux, php 5.2.6.

Original issue reported on code.google.com by swiatek....@gmail.com on 28 Nov 2008 at 2:14

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago

Original comment by swiatek....@gmail.com on 30 Nov 2008 at 3:04

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Yes, this was a problem.

Original comment by swiatek....@gmail.com on 18 Jan 2009 at 7:13

GoogleCodeExporter commented 9 years ago
What was the fix? I'm having the same issue.

Original comment by cvantas...@gmail.com on 21 Jan 2009 at 8:36

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
I'll put this into the FAQ.

Original comment by baron.schwartz on 5 May 2009 at 5:18

GoogleCodeExporter commented 9 years ago
This is in the FAQ.

Original comment by baron.schwartz on 24 Oct 2009 at 1:30

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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