Bad Gateway error, PHP 7.2, Linux and SA 17.0.10.5923

I'm running PHP 7.2 on Linux (Ubuntu 18.04) with SA 17.0.9.4935 and things are working fine.

If I upgrade SA17 to version SA 17.0.10.5923, the PHP 7.2 extension module fails with a Bad Gateway 402 error.

I've tried it with SA17 versions as far back as SA 17.0.10.5745 and they all fail with the 402 error.

The Linux PHP extension module is SQLAnywhere-php-7.2_Linux.tar.gz with SHA-1: e1a6a9e133075bd9bea2d411a327cf5c2e6d61fb

Is anyone running SA 17.0.10.xxxx successfully with PHP 7.2 on Linux?

############# UPDATE ############

I've now run this using the CLI, which should make it easier to reproduce. Here is an example:
<?php $cstring = "UID=DBA;PWD=*****;Server=newsatlasCN;DBN=newsatlassup;CS=UTF8"; $conn = sasql_connect( $cstring ); $payload = new stdClass(); if( $conn ) { $payload->meta = new stdClass(); $payload->rows = array(); $rs = sasql_query( $conn, "SELECT * FROM SYS.SYSCATALOG WHERE creator='SYS' AND tname='ISYSUSER'" ); if( $rs ) { while( $row = sasql_fetch_assoc( $rs ) ) { $payload->rows[] = $row; } sasql_free_result( $rs ); } header( "HTTP/1.1 200 OK" ); header( "Content-Type: application/json; charset=utf-8;" ); print json_encode( $payload ) . "\n"; sasql_disconnect( $conn ); } ?>

On SA 17.0.9.4935 and PHP 7.2.24-0ubuntu0.18.04.4 (cli), it runs properly with the expected output:

{"meta":{},"rows":[{"creator":"SYS","tname":"ISYSUSER","dbspacename":"system","tabletype":"TABLE","ncols":13,"primary_key":"Y","check":null,"remarks":null}]}

But on SA 17.0.10.5923, it crashes with the message:

PHP Warning: request_startup() for sqlanywhere module failed in Unknown on line 0

It seems to be failing in the call to the PHP extension module which, as noted above, is is SQLAnywhere-php-7.2_Linux.tar.gz with SHA-1: e1a6a9e133075bd9bea2d411a327cf5c2e6d61fb

Any ideas?

asked 14 Apr '20, 12:34

Terry Wilkinson
746●30●35●48
accept rate: 25%

edited 24 Apr '20, 12:20

I gave the Windows version a quick test and it seems to work. php -version PHP 7.2.30 (cli) (built: Apr 15 2020 09:15:11) ( ZTS MSVC15 (Visual C++ 2017) x64 ) I ran the query.php example. It uses the "demo" database. Can you run this? Is the "Bad Gateway 402" error occurring on a connect attempt? One major difference between .9 and .10 is the switch from OpenSSL to SAP Crypto.

(15 Apr '20, 10:37) JBSchueler

Replies hidden

The Windows version works. It's the Linux version that is failing. I'm calling it from a browser/nginx so the "Bad Gateway 402" error is coming because the PHP process fails. I have not tried it from CLI.

(15 Apr '20, 15:18) Terry Wilkinson

Comment Text Removed

I've updated the OP to show an example of the problem using the Linux CLI.

(21 Apr '20, 09:21) Terry Wilkinson

Does this code get off the ground? That is, are you making the database connection in line 2. I assume that the PHP extension module you are using has not changed from 17.0.9 to 17.0.10. The extension uses libdbcapi.so which is dependent on libdblib17_r.so and, probably, libdbtasks17_r.so. So can you try swapping these out for the version 17.0.9 files and see if that cures things? It will help narrow down the problem.

(22 Apr '20, 15:08) JBSchueler

Replies hidden

I also noticed that a similar issue was posted a few years ago: https://sqlanywhere-forum.sap.com/questions/27444/php-warning-request_startup-for-sqlanywhere-module-failed-in-unknown-on-line-0

Anything there that might be useful?

(22 Apr '20, 15:47) JBSchueler

Replies hidden

There is also this post on Stackoverflow with a similar problem: https://stackoverflow.com/questions/41139964/sqlanywhere-php-extension-errors-on-apache-restart Perhaps?

(22 Apr '20, 15:50) JBSchueler

Ok, I've added an initial print statement and there is no output, so I assume it does not "get off the ground".

I then replaced the 17.0.10 versions of libdblib17_r.so.1 and libdbtasks17_r.so.1 with the corresponding files from 17.0.9. It goes a bit farther but then it fails with

Warning: sasql_connect(): SQLAnywhere: [-832] Connection error: Missing or invalid encryption DLL "libsapcrypto.so" in /home/newsatlas/distros/php/test.php on line 3

However the file /opt/sqlanywhere17/lib64/libsapcrypto.so does exist.

(22 Apr '20, 16:12) Terry Wilkinson

I already have Environment=LD_LIBRARY_PATH=/opt/sqlanywhere17/lib64 defined so I don't think this is the problem - also the same configuration is working for 17.0.9.

(22 Apr '20, 16:24) Terry Wilkinson

Also related to Environment=LD_LIBRARY_PATH=/opt/sqlanywhere17/lib64 setting - working for 17.0.9 but not for 17.0.10.

(22 Apr '20, 16:28) Terry Wilkinson

Do you have a tool like strace or truss (I'm not sure of the name) that logs nitty-gritty stuff like shared object searches as the code is executing? It sounds like there is some sort of file search issue.

(22 Apr '20, 16:42) JBSchueler

No, unfortunately I don't have (or know how to use) those tools.

Are you able reproduce the problem on your systems?

(22 Apr '20, 17:04) Terry Wilkinson

Also check for lib64/libslcryptokernel.so and lib64/libslcryptokernel.so.sha256. I believe that both of these files are required by libsapcrypto.so. Maybe not. I checked the doc and apparently these are only used for the "fips" module, libsapcryptofips.so.

(22 Apr '20, 17:09) JBSchueler

I am working from home. Sorry, no Linux. I'll have to find someone with access to a Linux box.

(22 Apr '20, 17:18) JBSchueler

On 17.0.10, /opt/sqlanywhere17/lib64/libsapcrypto.so is there, but neither of the others.

On 17.0.9, none of them are there.

(22 Apr '20, 17:23) Terry Wilkinson

I don't use Linux so I have no clue at all - just want to mention that with 17.0.10.5745 the strategy to search for files such as shared libraries was changed, see the latest v17 readme, Engineering Case #819001. (No, I can't tell at all whether that may apply here.)

(23 Apr '20, 02:53) Volker Barth

Was SA 17.0.10.4745 a typo? There should be no issue as long as $sqlany17 is set correctly.

(23 Apr '20, 15:25) JBSchueler

I am also informed by the QA team that all php external environment tests have passed and continue to pass on Linux.

(23 Apr '20, 15:29) JBSchueler

On Linux: Executable files are searched using $SQLANY17/bin64 and PATH. Shared objects are searched using $SQLANY17/lib64 and LD_LIBRARY_PATH. Resource files are searched using $SQLANY17/res. Jar files are searched using $SQLANY17/java.

(23 Apr '20, 15:50) JBSchueler

Was SA 17.0.10.4745 a typo?

Can't tell that, I'm not the OP...

(24 Apr '20, 02:47) Volker Barth

Probably was a typo that should have been 17.0.10.5745 (I'll fix the OP)

(24 Apr '20, 12:19) Terry Wilkinson

More comments hidden

showing 4 of 20 show all flat view

One Answer:

active answers oldest answers newest answers popular answers

As Volker noted, the file search algorithm was tamed in 17.0.10 to address security issues (spoofed DLLs/shared objects). It is key that the customary SQLA install structure be maintained (bin64, lib64, res, etc hanging off the install root), that SQLANY17 point to the install root, and for OS static loading that LD_LIBRARY_PATH include the path to lib64, and that PATH include any directories where dynamically loaded executable programs are to be found. A message like this one, Missing or invalid encryption DLL "libsapcrypto.so", suggests something is off in the SQLANY17 setting.

permanent link

answered 24 Apr '20, 15:29

JBSchueler
3.3k●4●15●64
accept rate: 19%

converted 26 Apr '20, 08:00

Volker Barth
40.2k●361●550●822

I was beginning to suspect it was related to SQLANY17. I have LD_LIBRARY_PATH set correctly, but not SQLANY17.

I've now added a definition for SQLANY17 to the php-cgi configuration and it seems to be working. i.e., the config file /etc/php/7.2/fpm/pool.d/www.conf now has both lines

env[SQLANY17]=/opt/sqlanywhere17 env[LD_LIBRARY_PATH]=/opt/sqlanywhere17/lib64

Thanks. If you want to create an 'Answer', I can mark it correct.

(24 Apr '20, 15:39) Terry Wilkinson

Replies hidden

That's great. I am sure that I don't have to remind you to make sure to unswap those shared objects from 17.0.9. :-)

(24 Apr '20, 16:15) JBSchueler

Comment Text Removed

All the files in bin32/64 and lib32/64 have new dates that match the installation date, my application (PHP) is working fine, and I haven't had to make copies anywhere else, so I think all is well.

(25 Apr '20, 10:21) Terry Wilkinson

flat view

Your answer

toggle preview

community wiki:

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

learn more about Markdown

Question tags:

sa-17 ×246
php ×70
linux ×68
ubuntu ×18

question asked: 14 Apr '20, 12:34

question was seen: 1,883 times

last updated: 25 Apr '20, 10:21

SAP SQL Anywhere

Bad Gateway error, PHP 7.2, Linux and SA 17.0.10.5923

Follow this question

Related questions