Skip to main content
ExLibris
  • Subscribe by RSS
    • Back
    Aleph
    Ex Libris Knowledge Center

    Aleph won't start: "ORA-27140: attach to post/wait facility failed"

    1. Last updated
    2. Save as PDF
    • 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