- Article Type: General
- Product: Aleph
- Product Version: 18.01
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
but if I enter just:
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?
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".
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