Oracle 12c Installation on CentOS – Port Already in Use Error

0> "and set 5500 was impossible due to the error - 5500 seemed busy"

This means that the port 5500 is already "in use". Well, I bet it is not in use but Oracle thinks that. There are a lot of ports reserved in /etc/services.

Open the file and change the following lines:

fcp-addr-srvr1  5500/tcp                # fcp-addr-srvr1
fcp-addr-srvr1  5500/udp                # fcp-addr-srvr1

Change them into:

#fcp-addr-srvr1  5500/tcp                # fcp-addr-srvr1
#fcp-addr-srvr1  5500/udp                # fcp-addr-srvr1

Retry to set the port with SQL> EXEC dbms_xdb_config.sethttpport(5500);.

EDIT 1:

Your listener shows that it's listening on port 5500 for https requests. So maybe you already did what I just posted. Could you please share the output of the following command?

service iptables status

EDIT 2:

I just activated EM Express on one of my 12c databases. Here is what I did:

• OS: Oracle Linux 6.5
• DB: Oracle Database 12.1.0.2.0
• service iptables status --> OFF

Action log:

$ sqlplus / as sysdba
SQL> SELECT DBMS_XDB_CONFIG.gethttpport FROM dual;

GETHTTPSPORT
------------
        5500

SQL> SELECT DBMS_XDB_CONFIG.gethttpsport FROM dual;

GETHTTPPORT
-----------
          0

I'm going to set https port to 5501 and overwrite the http port with 5500.

SQL> EXEC DBMS_XDB_CONFIG.sethttpport(5500);
PL/SQL procedure successfully completed.

SQL> EXEC DBMS_XDB_CONFIG.sethttpsport(5501);
PL/SQL procedure successfully completed.

Afterwards the listener shows that I's listening on these ports (before the 5500 record was there already but it was not working)

$ lsnrctl status | grep PORT
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=***)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=***)(PORT=5501))(Security=(my_wallet_directory=/opt/oracle/admin/orcl/xdb_wallet))(Presentation=HTTP)(Session=RAW))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=***)(PORT=5500))(Presentation=HTTP)(Session=RAW))

I did the test in a browser:

• Browse to http://***:5500/em --> login screen appears
• Browse to https://***:5500/em --> login screen appears

Note the tailing "/em" is important.

After contacting Oracle support, I've -kinda- been able to figure out what was going on. This server has 4 network adaptors, 1 adaptor connected to the network, and 3 unconfigured adaptors connected to an iSCSI storage. The problem seems to be caused by the web-client, or EM server (not sure here) trying to send the webpage request to the wrong adaptor.

For anyone facing the same issue, you can check this by browsing to the URL (using the hostname.domain) and then checking the listener.log file (-oracle_base-/diag/tnslsnr/-instance-/listener/trace/listener.log). For me, in the error message a different IP address than the servers main network adaptors IP address was shown. The IP address of one of the network adaptors connected to the iSCSI where shown. When omitting the IP addresses in my original post, I didn't spot this IP address difference.

18-DEC-2015 14:17:04 * http * (ADDRESS=(PROTOCOL=tcps)(HOST=<NOT SERVER IP address!>%14)(PORT=62119)) * handoff * http * 12518
TNS-12518: TNS:listener could not hand off client connection
 TNS-12560: TNS:protocol adapter error

When disabling the additional network adaptors, everything works fine.

Additionally, when going to "chrome://net-internals/#dns" in chrome, the IP addresses of all four network adaptors showed up for my hostname.

Apparently, this problem -does not- happen, when browsing to the webpage from another host. Also, nslookup returns only the correct IP address. So it seems this is not a DNS issue, but a local issue. I think this is not a full answer to the problem, as disabling network adaptors can't be a final solution, but I hope anyone facing this issue in the future has "more to go on" now...

Where does the discrepancy between IP address returned by the DNS server, and the IP addresses used by web browsers come from?

I've also made some additional changes that might have influenced the end-solution, so for completeness I'll include them. Not sure if relevant...:

• Increased processes parameter of the database from 300 to 1000
• Altered the "dispatchers" parameter by adding "(DISPATCHERS=5)"