By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,352 Members | 1,645 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,352 IT Pros & Developers. It's quick & easy.

CLI CURL problem, happens only on the CLI?

P: n/a
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:

* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted

Again, if I view the script from the browser it runs fine, no errors..

I also tried running it as root on the CLI in case it was a
permissions problem.

When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:

CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6
More info:

$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
Jul 22 '08 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On Jul 22, 8:44 pm, Flexor <yugyu...@hotmail.comwrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:

* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted

Again, if I view the script from the browser it runs fine, no errors..

I also tried running it as root on the CLI in case it was a
permissions problem.

When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:

CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6

More info:

$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
So cURL is working in PHP but not from the CLI. So it's not really a
PHP question at all. So somewhat OT.

Things to check:

1) are either the web session or the webserver running in chroot jail?
2) is it just this HTTPS URL giving grief or is it all SSL?
3) when you run 'ldd' at the shell are all the libs in directories
described in /etc/ld.so.conf
4) start curl with strace or truss and see if it is able to load the
required binaries.

HTH

C.
Jul 23 '08 #2

P: n/a
On Jul 23, 8:11 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 22, 8:44 pm, Flexor <yugyu...@hotmail.comwrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
>
So cURL is working in PHP but not from the CLI. So it's not really a
PHP question at all. So somewhat OT.
No, the PHP script is not working (throws curl errors) when run on the
command line, but it works when run from the browser. I'm not running
curl on the command line directly, I'm just running the script. So it
is a PHP question.
1. no
2. it's all SSL
3. ]$ ldd
ldd: missing file arguments
Try `ldd --help' for more information.
4. stance nor truss are installed. Remember, curl has no problem when
the php script is run from the browser. So presumably curl is working
properly. If I run curl directly on the command line it can hit an
https site no problem.

Jul 23 '08 #3

P: n/a
On Jul 23, 4:21 pm, Flexor <yugyu...@hotmail.comwrote:
On Jul 23, 8:11 am, "C. (http://symcbean.blogspot.com/)"

<colin.mckin...@gmail.comwrote:
On Jul 22, 8:44 pm, Flexor <yugyu...@hotmail.comwrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
So cURL is working in PHP but not from the CLI. So it's not really a
PHP question at all. So somewhat OT.

No, the PHP script is not working (throws curl errors) when run on the
command line, but it works when run from the browser. I'm not running
curl on the command line directly, I'm just running the script. So it
is a PHP question.

1. no
2. it's all SSL
3. ]$ ldd
ldd: missing file arguments
Try `ldd --help' for more information.
4. stance nor truss are installed. Remember, curl has no problem when
the php script is run from the browser. So presumably curl is working
properly. If I run curl directly on the command line it can hit an
https site no problem.
Bit of confusion on my part - there is a CLI tool 'curl' which is a
wrapper around the lib - I'd recommend trying it on the URL.

You need to run ldd with the program its going to use - so in this
case:

ldd php

Check all the libs are where they are expected to be and readable for
your uid.

C.
Jul 24 '08 #4

P: n/a
On Jul 24, 6:37 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 23, 4:21 pm, Flexor <yugyu...@hotmail.comwrote:
On Jul 23, 8:11 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 22, 8:44 pm, Flexor <yugyu...@hotmail.comwrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
So cURL is working in PHP but not from the CLI. So it's not really a
PHP question at all. So somewhat OT.
No, the PHP script is not working (throws curl errors) when run on the
command line, but it works when run from the browser. I'm not running
curl on the command line directly, I'm just running the script. So it
is a PHP question.
1. no
2. it's all SSL
3. ]$ ldd
ldd: missing file arguments
Try `ldd --help' for more information.
4. stance nor truss are installed. Remember, curl has no problem when
the php script is run from the browser. So presumably curl is working
properly. If I run curl directly on the command line it can hit an
https site no problem.

Bit of confusion on my part - there is a CLI tool 'curl' which is a
wrapper around the lib - I'd recommend trying it on the URL.

You need to run ldd with the program its going to use - so in this
case:

ldd php

Check all the libs are where they are expected to be and readable for
your uid.

C.
OK:

$ ldd /usr/bin/php
libcrypt.so.1 =/lib/libcrypt.so.1 (0x00a52000)
libming.so.0 =/usr/local/ming-0.3.0//lib/libming.so.0
(0x0080e000)
libm.so.6 =/lib/tls/libm.so.6 (0x00a0b000)
libpng12.so.0 =/usr/lib/libpng12.so.0 (0x00b33000)
libjpeg.so.62 =/usr/lib/libjpeg.so.62 (0x00111000)
libcurl.so.3 =/usr/lib/libcurl.so.3 (0x00a84000)
libresolv.so.2 =/lib/libresolv.so.2 (0x00aef000)
libdl.so.2 =/lib/libdl.so.2 (0x00a05000)
libnsl.so.1 =/lib/libnsl.so.1 (0x00ad7000)
libssl.so.4 =/lib/libssl.so.4 (0x00d95000)
libcrypto.so.4 =/lib/libcrypto.so.4 (0x00caa000)
libgssapi_krb5.so.2 =/usr/lib/libgssapi_krb5.so.2
(0x00b0e000)
libkrb5.so.3 =/usr/lib/libkrb5.so.3 (0x00c20000)
libcom_err.so.2 =/lib/libcom_err.so.2 (0x00a30000)
libk5crypto.so.3 =/usr/lib/libk5crypto.so.3 (0x00c87000)
libidn.so.11 =/usr/lib/libidn.so.11 (0x0012f000)
libxml2.so.2 =/usr/lib/libxml2.so.2 (0x0015f000)
libpthread.so.0 =/lib/tls/libpthread.so.0 (0x00254000)
libc.so.6 =/lib/tls/libc.so.6 (0x008d7000)
libz.so.1 =/usr/lib/libz.so.1 (0x00a40000)
/lib/ld-linux.so.2 (0x008bd000)

Jul 25 '08 #5

P: n/a
Flexor wrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:

* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted

Again, if I view the script from the browser it runs fine, no errors..

I also tried running it as root on the CLI in case it was a
permissions problem.

When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:

CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6
More info:

$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib

Among other things, check your security settings. For instance, your
web server user may have access to a file or directory that your CLI
user doesn't.

The code doesn't change. Any time a script works on the web server but
not from the CLI (or vice versa), look for external factors - security
settings, library directories, etc.

Even the php.ini file may be in a different place, with completely
different options.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jul 25 '08 #6

P: n/a
On Jul 25, 1:57 am, Flexor <yugyu...@hotmail.comwrote:
On Jul 24, 6:37 am, "C. (http://symcbean.blogspot.com/)"

<colin.mckin...@gmail.comwrote:
On Jul 23, 4:21 pm, Flexor <yugyu...@hotmail.comwrote:
On Jul 23, 8:11 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 22, 8:44 pm, Flexor <yugyu...@hotmail.comwrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
So cURL is working in PHP but not from the CLI. So it's not really a
PHP question at all. So somewhat OT.
No, the PHP script is not working (throws curl errors) when run on the
command line, but it works when run from the browser. I'm not running
curl on the command line directly, I'm just running the script. So it
is a PHP question.
1. no
2. it's all SSL
3. ]$ ldd
ldd: missing file arguments
Try `ldd --help' for more information.
4. stance nor truss are installed. Remember, curl has no problem when
the php script is run from the browser. So presumably curl is working
properly. If I run curl directly on the command line it can hit an
https site no problem.
Bit of confusion on my part - there is a CLI tool 'curl' which is a
wrapper around the lib - I'd recommend trying it on the URL.
You need to run ldd with the program its going to use - so in this
case:
ldd php
Check all the libs are where they are expected to be and readable for
your uid.
C.

OK:

$ ldd /usr/bin/php
libcrypt.so.1 =/lib/libcrypt.so.1 (0x00a52000)
libming.so.0 =/usr/local/ming-0.3.0//lib/libming.so.0
(0x0080e000)
libm.so.6 =/lib/tls/libm.so.6 (0x00a0b000)
libpng12.so.0 =/usr/lib/libpng12.so.0 (0x00b33000)
libjpeg.so.62 =/usr/lib/libjpeg.so.62 (0x00111000)
libcurl.so.3 =/usr/lib/libcurl.so.3 (0x00a84000)
libresolv.so.2 =/lib/libresolv.so.2 (0x00aef000)
libdl.so.2 =/lib/libdl.so.2 (0x00a05000)
libnsl.so.1 =/lib/libnsl.so.1 (0x00ad7000)
libssl.so.4 =/lib/libssl.so.4 (0x00d95000)
libcrypto.so.4 =/lib/libcrypto.so.4 (0x00caa000)
libgssapi_krb5.so.2 =/usr/lib/libgssapi_krb5.so.2
(0x00b0e000)
libkrb5.so.3 =/usr/lib/libkrb5.so.3 (0x00c20000)
libcom_err.so.2 =/lib/libcom_err.so.2 (0x00a30000)
libk5crypto.so.3 =/usr/lib/libk5crypto.so.3 (0x00c87000)
libidn.so.11 =/usr/lib/libidn.so.11 (0x0012f000)
libxml2.so.2 =/usr/lib/libxml2.so.2 (0x0015f000)
libpthread.so.0 =/lib/tls/libpthread.so.0 (0x00254000)
libc.so.6 =/lib/tls/libc.so.6 (0x008d7000)
libz.so.1 =/usr/lib/libz.so.1 (0x00a40000)
/lib/ld-linux.so.2 (0x008bd000)
So what does

ls -l /usr/lib/libcurl.so.3

tell you? (this is probably a link - what are the permissions on the
link target)

C.
Jul 25 '08 #7

P: n/a
On Jul 24, 11:30 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
Flexor wrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted
Again, if I view the script from the browser it runs fine, no errors..
I also tried running it as root on the CLI in case it was a
permissions problem.
When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:
CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6
More info:
$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib

Among other things, check your security settings. For instance, your
web server user may have access to a file or directory that your CLI
user doesn't.

The code doesn't change. Any time a script works on the web server but
not from the CLI (or vice versa), look for external factors - security
settings, library directories, etc.

Even the php.ini file may be in a different place, with completely
different options.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
Thanks but as inidicated in my original post: "I also tried running it
as root on the CLI in case it was a permissions problem. " And
regarding the location of php.ini: "When I echo phpinfo() from the
CLI, it looks the same as when I print it in the browser. I even threw
in an obscure setting in there to compare it with both."
Jul 25 '08 #8

P: n/a
On Jul 25, 8:23 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 25, 1:57 am, Flexor <yugyu...@hotmail.comwrote:
On Jul 24, 6:37 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 23, 4:21 pm, Flexor <yugyu...@hotmail.comwrote:
On Jul 23, 8:11 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On Jul 22, 8:44 pm, Flexor <yugyu...@hotmail.comwrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
So cURL is working in PHP but not from the CLI. So it's not really a
PHP question at all. So somewhat OT.
No, the PHP script is not working (throws curl errors) when run on the
command line, but it works when run from the browser. I'm not running
curl on the command line directly, I'm just running the script. So it
is a PHP question.
1. no
2. it's all SSL
3. ]$ ldd
ldd: missing file arguments
Try `ldd --help' for more information.
4. stance nor truss are installed. Remember, curl has no problem when
the php script is run from the browser. So presumably curl is working
properly. If I run curl directly on the command line it can hit an
https site no problem.
Bit of confusion on my part - there is a CLI tool 'curl' which is a
wrapper around the lib - I'd recommend trying it on the URL.
You need to run ldd with the program its going to use - so in this
case:
ldd php
Check all the libs are where they are expected to be and readable for
your uid.
C.
OK:
$ ldd /usr/bin/php
libcrypt.so.1 =/lib/libcrypt.so.1 (0x00a52000)
libming.so.0 =/usr/local/ming-0.3.0//lib/libming.so.0
(0x0080e000)
libm.so.6 =/lib/tls/libm.so.6 (0x00a0b000)
libpng12.so.0 =/usr/lib/libpng12.so.0 (0x00b33000)
libjpeg.so.62 =/usr/lib/libjpeg.so.62 (0x00111000)
libcurl.so.3 =/usr/lib/libcurl.so.3 (0x00a84000)
libresolv.so.2 =/lib/libresolv.so.2 (0x00aef000)
libdl.so.2 =/lib/libdl.so.2 (0x00a05000)
libnsl.so.1 =/lib/libnsl.so.1 (0x00ad7000)
libssl.so.4 =/lib/libssl.so.4 (0x00d95000)
libcrypto.so.4 =/lib/libcrypto.so.4 (0x00caa000)
libgssapi_krb5.so.2 =/usr/lib/libgssapi_krb5.so.2
(0x00b0e000)
libkrb5.so.3 =/usr/lib/libkrb5.so.3 (0x00c20000)
libcom_err.so.2 =/lib/libcom_err.so.2 (0x00a30000)
libk5crypto.so.3 =/usr/lib/libk5crypto.so.3 (0x00c87000)
libidn.so.11 =/usr/lib/libidn.so.11 (0x0012f000)
libxml2.so.2 =/usr/lib/libxml2.so.2 (0x0015f000)
libpthread.so.0 =/lib/tls/libpthread.so.0 (0x00254000)
libc.so.6 =/lib/tls/libc.so.6 (0x008d7000)
libz.so.1 =/usr/lib/libz.so.1 (0x00a40000)
/lib/ld-linux.so.2 (0x008bd000)

So what does

ls -l /usr/lib/libcurl.so.3

tell you? (this is probably a link - what are the permissions on the
link target)

C.

$ ls -l /usr/lib/libcurl.so.3
lrwxrwxrwx 1 root root 16 Nov 11 2007 /usr/lib/libcurl.so.3 ->
libcurl.so.3.0.0
$ ll /usr/lib/libcurl.so.3.0.0
-rwxr-xr-x 1 root root 189696 May 2 2007 /usr/lib/libcurl.so.3.0.0
Jul 25 '08 #9

P: n/a
Flexor wrote:
On Jul 24, 11:30 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>Flexor wrote:
>>I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted
Again, if I view the script from the browser it runs fine, no errors..
I also tried running it as root on the CLI in case it was a
permissions problem.
When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:
CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6
More info:
$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
Among other things, check your security settings. For instance, your
web server user may have access to a file or directory that your CLI
user doesn't.

The code doesn't change. Any time a script works on the web server but
not from the CLI (or vice versa), look for external factors - security
settings, library directories, etc.

Even the php.ini file may be in a different place, with completely
different options.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

Thanks but as inidicated in my original post: "I also tried running it
as root on the CLI in case it was a permissions problem. " And
regarding the location of php.ini: "When I echo phpinfo() from the
CLI, it looks the same as when I print it in the browser. I even threw
in an obscure setting in there to compare it with both."
But it could still be a libpath problem or something similar. You could
even be running a different version of PHP between the web server and
the CLI.

Again - when a script works in one environment but not another, there is
almost always a difference in the environments which cause the problem.
The only exception would be some obscure function calls which exist in
one but not the other. But if that's the case you'll get an error
message (function not found).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 25 '08 #10

P: n/a
On Jul 25, 12:24 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
Flexor wrote:
On Jul 24, 11:30 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
Flexor wrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted
Again, if I view the script from the browser it runs fine, no errors..
I also tried running it as root on the CLI in case it was a
permissions problem.
When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:
CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6
More info:
$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
Among other things, check your security settings. For instance, your
web server user may have access to a file or directory that your CLI
user doesn't.
The code doesn't change. Any time a script works on the web server but
not from the CLI (or vice versa), look for external factors - security
settings, library directories, etc.
Even the php.ini file may be in a different place, with completely
different options.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
Thanks but as inidicated in my original post: "I also tried running it
as root on the CLI in case it was a permissions problem. " And
regarding the location of php.ini: "When I echo phpinfo() from the
CLI, it looks the same as when I print it in the browser. I even threw
in an obscure setting in there to compare it with both."

But it could still be a libpath problem or something similar. You could
even be running a different version of PHP between the web server and
the CLI.

Again - when a script works in one environment but not another, there is
almost always a difference in the environments which cause the problem.
The only exception would be some obscure function calls which exist in
one but not the other. But if that's the case you'll get an error
message (function not found).

I don't disagree that it's the environment. The bang line points to
the same php that apache uses. And a comparison of phpinfo()
indicates the same php path for both.

Jul 25 '08 #11

P: n/a
Flexor wrote:
On Jul 25, 12:24 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>Flexor wrote:
>>On Jul 24, 11:30 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
Flexor wrote:
I have a php script that runs from command line and makes an https
request to paypal, using curl. It works fine if I run it from a web
page. It fails if I run it from CLI. The error I get from the CLI:
* About to connect() to api-3t.sandbox.paypal.com port 443
* Trying 216.113.191.88... * connected
* Connected to api-3t.sandbox.paypal.com (216.113.191.88) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/ssl/certs/ca-bundle.crt
CApath: none
* Unknown SSL protocol error in connection to
api-3t.sandbox.paypal.com:443
* Closing connection #0
*** glibc detected *** free(): invalid pointer: 0x00dc8c80 ***
Aborted
Again, if I view the script from the browser it runs fine, no errors..
I also tried running it as root on the CLI in case it was a
permissions problem.
When I echo phpinfo() from the CLI, it looks the same as when I print
it in the browser. I even threw in an obscure setting in there to
compare it with both. CURL shows up in both:
CURL support =enabled
CURL Information =libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.3 libidn/
0.5.6
More info:
$ php -v
PHP 5.1.4 (cli) (built: Jun 8 2006 18:09:19)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
$ php -m
[PHP Modules]
ctype
curl
date
dom
ftp
gd
hash
iconv
libxml
ming
mysqli
pcre
PDO
posix
Reflection
session
SimpleXML
soap
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
Among other things, check your security settings. For instance, your
web server user may have access to a file or directory that your CLI
user doesn't.
The code doesn't change. Any time a script works on the web server but
not from the CLI (or vice versa), look for external factors - security
settings, library directories, etc.
Even the php.ini file may be in a different place, with completely
different options.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
Thanks but as inidicated in my original post: "I also tried running it
as root on the CLI in case it was a permissions problem. " And
regarding the location of php.ini: "When I echo phpinfo() from the
CLI, it looks the same as when I print it in the browser. I even threw
in an obscure setting in there to compare it with both."
But it could still be a libpath problem or something similar. You could
even be running a different version of PHP between the web server and
the CLI.

Again - when a script works in one environment but not another, there is
almost always a difference in the environments which cause the problem.
The only exception would be some obscure function calls which exist in
one but not the other. But if that's the case you'll get an error
message (function not found).


I don't disagree that it's the environment. The bang line points to
the same php that apache uses. And a comparison of phpinfo()
indicates the same php path for both.

If Apache is loading PHP as a module, then no, it isn't using the same
one. If Apache is loading as a CGI, it may or may not be the same file.
It all depends.

But what about my other questions - have you checked the rest of the
environment, i.e. libs, etc. Something is different.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 26 '08 #12

This discussion thread is closed

Replies have been disabled for this discussion.