Can't start Apache with Oracle10g on OpenVMS

[Z.K.]

Hi all,
We have Apache2.0(with php4), Oracle 10g installed on a HP Integrity RX4640 machine(OpenVMS V8.3), but we can't start apache server now.
We found this error in the log file:
$ type apache$sws.log
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
%DCL-I-SUPERSEDE, previous value of APACHE$OCI_SHR has been superseded
%DCL-I-SUPERSEDE, previous value of ORACLE_HOME has been superseded
%DCL-I-SUPERSEDE, previous value of ORACLE_SID has been superseded
%DCL-I-SUPERSEDE, previous value of ORACLE_BASE has been superseded
%DCL-I-SUPERSEDE, previous value of PATH has been superseded
%DCL-I-SUPERSEDE, previous value of TNS_ADMIN has been superseded
%DCL-I-SUPERSEDE, previous value of NLS_LANG has been superseded
%DCL-I-SUPERSEDE, previous value of ORA_NLS33 has been superseded
%DCL-I-SUPERSEDE, previous value of LD_LIBRARY_PATH has been superseded
[Wed Jan 30 10:38:16 2008] [warn] module php4_module is already loaded, skipping
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0024, PC=00000000030EA280, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC

libclntsh lxhcsn lxhcsn 117278 0000000000000010 00000000030EA280
libclntsh kod kodosgi 1413547 0000000000000230 000000000242FEC0
libclntsh kouo kouogini 1008240 00000000000013F0 00000000012C8390
libclntsh kouo kouoini 1008499 0000000000002E80 00000000012C9E20
libclntsh kpuini kpuinit0 1082919 000000000001EFD0 00000000010B23C0
libclntsh kpuini kpuinit #3707 000000000001B410 00000000010AE800
libclntsh oci8 OCIEnvInit 469872 00000000000006E0 0000000000DFB040
PHP_OCI8 0 000000000004F920 0000000000CAD920
PHP_OCI8 0 00000000000301D0 0000000000C8E1D0
PHPSHR 0 00000000000F4800 000000000062E800
PHPSHR 0 00000000001836A0 00000000006BD6A0
PHPSHR 0 000000000023FC30 0000000000779C30
PHPSHR 0 0000000000184430 00000000006BE430
PHPSHR 0 0000000000196970 00000000006D0970
MOD_PHP_APACHE-2_0 0 0000000000030EA0 000000000054AEA0
MOD_PHP_APACHE-2_0 0 0000000000031280 000000000054B280
APACHE$HTTPD_SHR CONFIG ap_run_post_config
50629 0000000000000770 000000000029F9A0
APACHE$HTTPD MAIN main 50412 0000000000001E10 0000000000011E10
APACHE$HTTPD MAIN __main 50141 0000000000000870 0000000000010870
0 FFFFFFFF80B5D920 FFFFFFFF80B5D920
DCL 0 000000000006B9C0 000000007AE1B9C0
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump
APACHE$WWW job terminated at 30-JAN-2008 10:38:18.51

Accounting information:
Buffered I/O count: 909 Peak working set size: 35856
Direct I/O count: 238 Peak virtual size: 428752
Page faults: 4186 Mounted volumes: 0
Charged CPU time: 0 00:00:00.67 Elapsed time: 0 00:00:01.76

Can anybody help us.
Thanks in advance!
zhaokai

[Willem Grooters]

Assuming you have the latest MOD_PHP from HP, this is 'known behaviour'

CSWS_PHP Version 1.3 runs with HP Secure Web Server Versions 1.3-1 and 2.1 and higher for OpenVMS Alpha and I64. It does not work with SWS Version 2.0.

The best you can do is update to SWS 2.1, it has some benefits bisides that. Have all updates to CRTL and PThreads installed as well.

Besides that: there are (some) issues with this MOD_PHP and some og the extensions. I wouldn't be very surprised if the oracle extension has some.

[Hoff]

And FWIW, the php4 version itself has gone (mostly) end-of-life; it's retired for all but the most critical of security fixes, and those will reportedly end on 08-Aug-2008. Barring critical security fixes needed prior to 8-8-8, the end of the php4 version line is 4.4.8.

The upgrade path is to php5.

[Z.K.]

Sorry, I made a mistake.
The version of apache is: HP I64VMS CSWS V2.1-1
and the version of PHP is HP I64VMS CSWS_PHP V1.3
I'll try to find if there're any new version of PHP.

[Z.K.]

I've installed two patches:
HP-I64VMS-CSWS211_UPDATE-V0100--4.PCSI_SFX_I64EXE
HP-I64VMS-CSWS_PHP13_UPDATE-V0100--4.PCSI_SFX_I64EXE
But still to no use.

[Willem Grooters]

You won't find a new version of MOD-PHP for OpenVMS yet.

Another question: Does the error show up at the start of Apache, or when your PHP code is started?

Given the stackdump, the problem is in the Oracle module (PHP_OCI8) - my impression, by this name, is that is to be used with Oracle 8 and can probably not be used with Oracle10.
I'd raise a call with HP to get that fixed. Doing it yourself (like some did with the MySQL extension) is possible but requires some digging how to achieve it.

Another thing you may take a look at, is the location and protection of all images involved. My experience with PHP is that ACL-based protection is not recognized by all code and files needs to be W:R at least to be accesable. ACCVIO seems tio be a 'valid' result if this test fails.

[Z.K.]

Yes, apache crash during startup, not at PHP script execution. I changed the configuration file PHP.INI, when I comment the line of "PHP_OCL8", the apache will start successfully, but when I uncomment that line, apache'll crash during startup.

[Willem Grooters · Accepted solution]

That feeds suspicion on the module PHP_OCI8. As stated, that might be a module to access Oracle8 and might not work with Oracle10.
Something you could try: Does PHP itself work? AFAIK, there are some PHP scripts that come with MOD_PHP you can use to check, I think PGP_RULES.PHP will do:

$ PHP PHP_RULES.PHP

(You will need to define PHP as a foreign command)
Try this with PHP_ORI8 enabled in PHP.INI. If it works, see if you can get a PHP code that accesses your oracle database and do the same. If this works, the problem is really within the PHP Oracle extension.

[Duncan Morris]

You can get further information about that module from

http://uk.php.net/oci8

The lastest version certainly supports Oracle 10g, but whether the version supplied with CSWS_PHP would, is debatable!

Duncan

[Duncan Morris]

OCI Extension
Add the following lines to the beginning of the file APACHE$COMMON:[000000]LOGIN.COM:

For Oracle 8i:

$ !
$ ! Define the OCI extension logicals if we find the OCI client shareable
$ !
$ IF F$SEARCH ("ORA_ROOT:[UTIL]ORACLIENT_V817.EXE") .NES. ""
$ THEN
$ DEFINE APACHE$OCI_SHR ORA_ROOT:[UTIL]ORACLIENT_V817.EXE
$ ENDIF

For Oracle 9i:

$ !
$ ! Define the OCI extension logicals if we find the OCI client shareable
$ !
$ IF F$SEARCH ("ORA_ROOT:[LIB32]LIBCLNTSH.SO") .NES. ""
$ THEN
$ DEFINE APACHE$OCI_SHR ORA_ROOT:[LIB32]LIBCLNTSH.SO
$ ENDIF

The two logicals required to make the OCI extension functional are APACHE$OCI_SHR and
APACHE$OCI_PFX. These logicals are defined as follows:

APACHE$OCI_SHR

This logical defines the OCI8 shareable image to be used for the OCI8 access.

APACHE$OCI_PFX

This logical defines, if needed, any OCI8 API prefix.

I would image that you would need to modify the 9i approach to reflect your 10g environment. Have you tried anything like this yet?