Originally Posted by TenTenths
The file /etc/services should give you a list of the well known ports for services.
Linux will not allocate/use an ephemeral port if there is a process listening on it so as long as your developers don't listen on any of the "well known" ports they'll be fine.
(Actually they CAN listen on any of the well known ports, just be aware that if they do and you later decide to run a well known application then there will be a conflict. For example they could run their fongdaemon on port 80 if they wanted to but as soon as you want to install a web server........)
That's helpful for my wiki so that guys in future don't use these ports.
One of the usecase is for instance, my application acquires port 33000 and when linux is about to allocate the same port for ephemeral, OS checks that it is not free and moves on to perhaps 33001. Problem is some of our application are scheduled to be running in EMEA / APAC / NA time zones. So next day I can expect a scenario where application hardcoded to listen at 33000 is sleeping. OS find 33000 as free and allocates it, later when my app wakes up and tries to open a socket it fails. This is exactly what I want to address.
This is a scenario for a bank where I have hybrid environment and applications from different vendors / internal and all running and playing with the system. I have managed to sort 70 % of them such that they allocate port in the range of 31000-32000.
I was hoping netstat or perhaps some other utlility to tell me like the below port 49945 acquired by java app 21203 is actually a port given to him by OS. He did not hardcode it
tcp 0 0 0.0.0.0:49945 0.0.0.0:* LISTEN 21023/java
as against this app, which hardcoced it
tcp 0 0 0.0.0.0:13111 0.0.0.0:* LISTEN 4612/prod1
netstat output happens to be same for both instances
Common sense would say that 49945 looks like an ephemeral one and most likely given by OS. Apparently sometimes you are stcuk up in environment where common sense is not that common.
So any further help is much appreciated.