• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
When I run $aleph_startup from the $alephe_root directory on our LIBPRDDB1 server, I get the following error:

Oracle error: handle_connection

ORA-27140: attach to post/wait facility failed <-----

Oracle not running !!!

We don't see any changes to the permissions on $ORACLE_HOME/bin or any other directories.

After rebooting the server, I can successfully connect to Oracle doing

sqlplus aleph_dba/aleph_dba@libprddb1.aleph1

but if I enter just:

sqlplus

and then enter "aleph_dba" as the username ans password, I get:

ORA-01034: ORACLE not available
ORA-27123: unable to attach to shared memory segment
Linux Error: 13: Permission denied

(the same error that we get running the aleph_startup script). Could an environment variable be missing that specifies aleph1 as the database?

Resolution:
[From site:]
Searching Google for the new error messages I got after the reboot took me straight to this page: http://sabdarsyed.blogspot.com/2009/01/ora-27123-unable-to-attach-to-shared.html , and when I compared the file permissions on LIBPRDDB1 ORACLE_HOME/bin/oracle to the same file on LIBTSTDB , the difference in permissions exactly matched what that page indicated. I changed the permissions on the LIBPRDDB1 oracle file, but that didn’t fix the problem, and now that I look at all the files in ORACLE_HOME on LIBPRDDB1, I see that all the permissions are different than the same files on LIBTSTDB. Unfortunately, not all the files in $ORACLE_HOME/bin have the same permissions, so I don’t think I can just do a “chmod [permissions] *” command. But re-setting the permissions file by file corrected the problem.

The gist of the problem was the "SUID" file permission on the Oracle executables having been changed from "s" to "x".

[From Jerry:]
As to the possibility of a script, looking in $aleph_proc, I find a script fix_libtool.csh which does "chmod +x" for a specific file (or, perhaps, directory).

This script was introduced with v18 rep_change 1000, which says, "Fixing a file for compilation of mod_aleph_2 on Solaris."

I see that libprddb1 is Linux, so it seems that this script would not be relevant to your server.

I know that I did not execute this script and do not believe anyone else from Ex Libris did.

I do not think that we will be able to find the cause of this problem in this case. I would say that all we can do is to wait and see if it happens again.

• Article last edited: 10/8/2013