Error message: port already in use

Sometimes it happens that an installation fails with the error message "port already in use" (this can be the case with the Oracle snmpx daemon on UNIX systems).
If you don't know which TCP port is generating the error, the following UNIX command lists those currently being used.


oracle@:PROD1 >netstat -an | grep LISTEN | sort -k 1 
      *.111                *.*                0      0 24576      0 LISTEN
      *.13                 *.*                0      0 24576      0 LISTEN
      *.161                *.*                0      0 24576      0 LISTEN
      *.19                 *.*                0      0 24576      0 LISTEN
      *.2049               *.*                0      0 24576      0 LISTEN
      *.21                 *.*                0      0 24576      0 LISTEN
      *.23                 *.*                0      0 24576      0 LISTEN
      *.2410               *.*                0      0 24576      0 LISTEN
... ... 
      *.898                *.*                0      0 24576      0 LISTEN
      *.9                  *.*                0      0 24576      0 LISTEN
      *.9991               *.*                0      0 24576      0 LISTEN
179.146.111.76.1521        *.*                0      0 24576      0 LISTEN

This list shows the port 21 (ftp), 23 (telnet), 1521 (an Oracle listener) etc. If you suspect of a particular TCP port (for example 161) go for it.


netstat -an | grep 161

      *.161                *.*                0      0 24576      0 LISTEN

Find the process that is using the TCP port

It is now necessary to find out which process is actually using the TCP port. On the Internet an open source tool called lsof is available, but if you don't feel like installing another tool, the following short script can do the work.
The script goes through the process tables and finds out which one is already using a certain port. You need root privileges to run this script.


for PROC in /proc/*
do
  echo $PROC
  pfiles -F $PROC | grep port |grep 161
done

A sample output is


..
/proc/76
/proc/777
        sockname: AF_INET 0.0.0.0  port: 161
        sockname: AF_INET 179.146.111.98   port: 161
        sockname: AF_INET 179.146.111.101  port: 161
        sockname: AF_INET 179.146.111.102  port: 161
        sockname: AF_INET 179.146.111.100  port: 161
/proc/779
/proc/784
...

We have now got the process ID 777 and it is easy to determine what it is doing :


app@serverdaddy[on pts/1] ps -ef | grep 777
    root   777  717  0   Dec 05 ? 11:28 /opt/buw/bin/snmpd -f -x -s g_mon -l

Our investigation is therefore completed: the TCP port 161 is being used by the process /opt/buw/bin/snmpd.

A real case: Could not start agent. Initialization failure

Sometimes it happens, especially after an updrade, to come across the error:

Failed while initializing Collection Service
Error initializing subsystems
Agent exited at Thu Jan 27 11:00:54 MET 2005 with return value 55
Could not start agent. Initialization failure


oracle@zhru09 [oracle] # pwd
/opt/oracle/9.2.0.5/network/log
oracle@dbserver [oracle] # ls -ltr
total 6
-rw-rw----   1 oracle   dba          278 Jan 27 11:00 nmiconf.log
-rw-r-----   1 oracle   dba          267 Jan 27 11:00 dbsnmp.nohup
-rw-rw----   1 oracle   dba          585 Jan 27 11:00 dbsnmp.log

The contents of dbsnmp.nohup are:


oracle@dbserver [oracle] # cat dbsnmp.nohup

------------------------ Thu Jan 27 11:00:49 MET 2005 ------------------------
Failed while initializing Collection Service
Error initializing subsystems
Agent exited at Thu Jan 27 11:00:54 MET 2005 with return value 55
Could not start agent. Initialization failure

The contents of dbsnmp.log are:

oracle@dbserver [oracle] # cat dbsnmp.log

DBSNMP for Solaris: Version 9.2.0.5.0 - Production on 27-JAN-2005 11:00:52

Copyright (c) 2003 Oracle Corporation.  All rights reserved.

System parameter file is /var/opt/oracle/snmp_ro.ora
Log messages written to /opt/oracle/9.2.0.5/network/log/dbsnmp.log
Trace information written to /opt/oracle/9.2.0.5/network/trace/dbsnmp_6038.trc
Trace level is currently 0

NMS-00001: Warning: dbsnmp unable to connect to SNMP master agent
11:00:54 27/01/2005
ODG-05019: Error: failed to bind socket
11:00:54 27/01/2005
ODG-05083: Error: failed to allocate listening port/socket

The explanation in the Oracle Metalink for the error ODG-05083 is:


Error:	ODG-5083 Text:	Error: failed to allocate listening port/socket
  --------------------------------------------------------------------------- 

Cause:	an error occurred while attempting to open the Data Gatherer socket 
 	
(1808).  
Action:	
ensure that no other process is using this socket and retry the operation

Therefore, withe script above, let's check whether some other process is already using the port 1808:



sysuser@dbserver[on pts/5] netstat -a |egrep -i 1808
dbserver.1808                *.*                0      0 24576      0 LISTEN

for PROC in /proc/*
do
  echo $PROC
  pfiles -F $PROC | grep port |grep 1808
done

...
/proc/1162
/proc/1165
/proc/3687
/proc/3689
/proc/3691
/proc/4429
        sockname: AF_INET 169.166.228.84  port: 1808
/proc/5632
... ...

root@dbserver[on pts/7]# ps -aef|grep -i 4429
    root  7961  6922  0 11:36:15 pts/7    0:00 grep -i 4429
  oracle  4429     1  0   Dec 09 ?       43:56 /u00/app/oracle/product/8.1.7/bin/vppdc
root@dbserver[on pts/7]# kill -3 4429
root@dbserver[on pts/7]# kill -5 4429
root@dbserver[on pts/7]# kill -9 4429

The problem, therefore, was that the data gatherer of version 8.1.7 was still running. The reason why sometimes we forget this process is that the agent in 9i is also the data gatherer.
Again, this is a real case.

[Home] [Web Design] [HTML tutorials] [Javascript] [PSP] [About us] [Links] [Anonymous email] [Best hosting] [Daily Oracle Life] [IT jobs in Switzerland] [Web Submission] [Web traffic]

Rate this article ...
Very poor	Poor	Average	Good	Very good