My stack:

  • CentOS 7.2.1511 (x64)
  • Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
  • SQL Anywhere 17.0.0.1062

I have built the sqlanywhere php module exactly as the documentation instructs, plus added the path /opt/sqlanywhere17/lib64 to the library cache.

When I enable the extension (by adding extension=sqlanywhere.so in php.ini), it fails to load:

[Mon Jun 13 15:14:21.979308 2016] [:error] [pid 6259] [client 24.176.93.67:54860] PHP Warning: request_startup() for sqlanywhere module failed in Unknown on line 0

Any assistance would be greatly appreciated.

asked 13 Jun '16, 11:24

mmellon's gravatar image

mmellon
1464410
accept rate: 25%


Adding: Environment=LD_LIBRARY_PATH=/opt/sqlanywhere17/lib64

at the beginning of [Service] section in the httpd.service file solved the problem in my case.

permanent link

answered 04 May '17, 10:07

Przemek%20Roman's gravatar image

Przemek Roman
302
accept rate: 0%

You likely need more than just some shared libraries here. There are resource files required as well (.\res*) for language support.

Depending upon other requirements there could be other files needed as well.

To test if you have a sufficient set you can always source sa_config.sh/.csh ahead of launching either Apache or PHP (if standalone). That should just work; afterwards you can tease the minimum set of files into the extensions directory.

permanent link

answered 13 Jun '16, 12:48

Nick%20Elson%20SAP%20SQL%20Anywhere's gravatar image

Nick Elson S...
7.3k35107
accept rate: 32%

edited 14 Jun '16, 11:36

Thanks, Nick.

I tried... but no dice:

[root@ip-10-88-0-4 ~]# apachectl stop
[root@ip-10-88-0-4 ~]# source /opt/sqlanywhere17/bin64/sa_config.sh
[root@ip-10-88-0-4 ~]# apachectl start
[root@ip-10-88-0-4 ~]# wget https://ecosystem.ecrsoft.com/phpinfo.php
--2016-06-13 17:36:20--  https://ecosystem.ecrsoft.com/phpinfo.php
Resolving ecosystem.ecrsoft.com (ecosystem.ecrsoft.com)... 52.38.221.237
Connecting to ecosystem.ecrsoft.com (ecosystem.ecrsoft.com)|52.38.221.237|:443... connected.
HTTP request sent, awaiting response... No data received.

The request causes the following error to be logged still (from /var/log/httpd/ssl_error_log):

[Mon Jun 13 17:36:21.365026 2016] [:error] [pid 6707] [client 52.38.221.237:49276] PHP Warning:  request_startup() for sqlanywhere module failed in Unknown on line 0

However, the client driver is loading in cli:

[root@ip-10-88-0-4 ~]# php --info
...
SQLAnywhere support => enabled Allow
Persistent Connections => Yes
Persistent Connections => 140230848155952/14023084815604 Total
Connections => 140230848155888/14023084815601 PHP
SQLAnywhere driver version => 2.0.16.1 SQLAnywhere client version => 17.0.0.1062
...

So, PHP can find the extension and load the driver, but not when invoked as an httpd module.

(13 Jun '16, 13:47) mmellon
Replies hidden
(14 Jun '16, 10:57) JBSchueler
Replies hidden

Yes. That article, in particular, addresses the EXTERNAL ENVIRONMENT features (calling PHP within the database). It had crossed my mind that I might be using the a threaded extension with a non-thread-safe php... but...

When I run php using the CLI API, I get:

Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
Additional .ini files parsed => /etc/php.d/curl.ini,
/etc/php.d/fileinfo.ini,
/etc/php.d/json.ini,
/etc/php.d/phar.ini,
/etc/php.d/zip.ini

PHP API => 20100412
PHP Extension => 20100525
Zend Extension => 220100525
Zend Extension Build => API220100525,NTS
PHP Extension Build => API20100525,NTS
Debug Build => no
Thread Safety => disabled
Zend Signal Handling => disabled
Zend Memory Manager => enabled
Zend Multibyte Support => disabled
IPv6 Support => enabled
DTrace Support => disabled

Note that thread safety was disabled.

If I run it as CGI, I get:

PHP Version 5.4.16

System  Linux ip-10-88-0-4.us-west-2.compute.internal 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64
Build Date  May 12 2016 13:45:08
Server API  CGI/FastCGI
Virtual Directory Support   disabled
Configuration File (php.ini) Path   /etc
Loaded Configuration File   /etc/php.ini
Scan this dir for additional .ini files /etc/php.d
Additional .ini files parsed    /etc/php.d/curl.ini, /etc/php.d/fileinfo.ini, /etc/php.d/json.ini, /etc/php.d/phar.ini, /etc/php.d/zip.ini
PHP API 20100412
PHP Extension   20100525
Zend Extension  220100525
Zend Extension Build    API220100525,NTS
PHP Extension Build API20100525,NTS
Debug Build no
Thread Safety   disabled
Zend Signal Handling    disabled
Zend Memory Manager enabled
Zend Multibyte Support  disabled
IPv6 Support    enabled
DTrace Support  disabled
Registered PHP Streams  https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters   zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk

CLI loads the module+driver and is happy. CGI crashes with the "PHP Warning: request_startup() for sqlanywhere module failed in Unknown on line 0" error if I enable the extension. But thread safety is off in both server API's, so that can't be the problem, since it works in CLI and not CGI...

I thought perhaps PHP wasn't getting the environment from /opt/sqlanywhere17/lib64/sa_config.sh, but that's not the case according to the httpd docs: https://httpd.apache.org/docs/current/env.html. I have made sure to add the PassEnv directive for LD_LIBRARY_PATH and PATH.

My objective is to make it work with the php module, not with php-cgi. I have the same symptom either way. I must get this to work with httpd - this is becoming quite urgent.

Note also that make does not compile an sqlanywhere_r.so on this system... it only produces sqlanywhere.so.

(14 Jun '16, 16:47) mmellon

Just as a wild guess:

17.0.0.1062 is the GA version, there are newer builds available, and the latest v17 readme names a few fixes related to PHP. Note, I don't claim they affect your situation...

(15 Jun '16, 03:47) Volker Barth

I just ran the upgrade to 17.0.4.2053, went back to the sdk/php path, ./configured, make clean, make, make test, make install...

...restarted httpd

same symptom.

(15 Jun '16, 11:06) mmellon

SO .... - Foreground PHP can find everything from the environment. - Daemon apache loading PHP is not able. That usually means the httpd process's environment is different and that usually means missing libraries and resource files.

Do make sure you've copied all of the required libs and .res files to your extenion directory. [see my earlier link other files needed At a minimum you will require dblgeng17.res and any others required to match your lang/locale settings.

(15 Jun '16, 11:29) Nick Elson S...
showing 3 of 6 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×70

question asked: 13 Jun '16, 11:24

question was seen: 47,742 times

last updated: 04 May '17, 10:07