Discussion Locked

Why Port 6689 cannot be released

0 helpful
5 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

We have a web and Java based portal application called Viador running on Solaris 2.6. Viador is an application server that besides many other things consists of some JAVA processes. Viador server (software) can be stopped and re-started by application support group if there is problem (e.g., if application is responding slow etc.) It needs port # 6689 to run. It uses JRUN (the Java application server) and Netscape Web server to function. We often re-cycle Viador software to improve performance. But something strange happened recently. A few days ago the Unix box on which Viador is running had crashed and had to be restored from the back-up tape. After the server was restored, we can no longer stop and start Viador application server.When we attempt to restart Viador we get the error message "Port 6689 is unavailable".

Since Viador needs port 6689 to function, it cannot be started until port #6689 is free and available. Our Unix SA has NOT been able to find the cause of port not being released. Also it cannot be determined which process is using and or keeping this port hostage and why the port cannot be released. Currently the only solution is to bring down and re-start Unix operation system. We do not like this solution since we have to depend on SA to do this. Also we should NOT have to re-boot Unix just to release a port from some rouge runaway process which cannot be identified.

Question: Is there any way to find out which process is using the port # 6689 and is there any command to release that port without re-booting Unix operating system. I believe there must be a command to identify which process is keeping this port hostage and free it up.

Any help would be highly appreciated. Thanks

5 replies

by cpfeiffe

netstat -a will list all of the ports that have veen opened and their current status, as well as a connection to any other system. This may give you a long list so when you run it you should page the output so you can scroll a little at a time 'netstat -a |more'. Since, any established connections will show you what machine and what port has established the connection you or at least your unix SA should be able to figure out what has held it open. My guess is that it is pretty simple and that the application isn't shutting down properly any longer when you restart it. In that case the port may show as bound, but not established and I think that is what you will see. A tape restore will sometimes result in this, depending on how it is done. If the entire system crashed and the OS had to be rebuilt, then the tape restore was applied you can't be sure the OS was built the same way (special permissions set, config files, etc.). If a tape restore was done, but not to the OS something in a part of the OS thought to be safe may be damaged/gone. It could be as simple as a missing link. I would look at your application's log files. If it is currently logging you should start logging. You should also find out if you can enable debugging for the daemon running on this port and do so, then review its logs. Other than that netstat -a is a great start.

by akhan

The problem was permission related and possibly was caused by the restore process. It has been fixed by our . SA was already using the netstat comand to monitor the port. Your answer reconfirmed our thinking. Thanks a lot

by kumar_nh

I presume that your Java Application is a client-server application. In such a scenario, then you java application uses most often port 6689 to access the RDBMS(Back-end). So when you are closing the application, port is not released properly by theJava application. What you could try is, first stop the database service, and JDBC service(if possible, i am not sure) then close your application. This could be one of the possible solution.

This discussion is closed to new replies.