Linux – How todentify Port to a Process

My guess is it's a firewall issue. To diagnose, either switch to root or use sudo to execute these commands described below:

Firstly, service iptables status will show you your current rules. Depending on how esoteric your firewall rules are, you may need to add them into the main question to debug but essentially you're looking for a line that accepts TCP port 8800 prior to a line that rejects all connections.

e.g.

Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source       destination
...
14   ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0      state NEW tcp dpt:8800
15   REJECT     all  --  0.0.0.0/0    0.0.0.0/0      reject-with icmp-host-prohibited

If you don't have a REJECT line on your input chain, then the firewall is probably already turned off.

One way to get around this is obviously to turn off the firewall (service iptables stop) although this defeats the entire purpose of having a firewall.

If you need to add a new firewall rule, you have a couple of options:

1. Use the excellent Firewall Configuration tool (system-config-firewall) that ships with Fedora and can be found at the System->Administration->Firewall menu item in Gnome.

2. On the command line, insert a new rule before the REJECT rule by executing the following (uses numbers from my example above): iptables -I INPUT 15 -m state --state NEW -m tcp -p tcp --dport 8800 -j ACCEPT. NOTE that these changes are not permanent and will not persist beyond the next reboot.

3. Manually edit the /etc/sysconfig/iptables file and add a rule (-A INPUT -m state --state NEW -m tcp -p tcp --dport 8800 -j ACCEPT) to the firewall prior to the REJECT rule. Cycle the firewall service to pick up the changes via a service iptables restart. These changes will be applied every time the firewall service is started.

Although people are pointing out specific services (e.g. the "Web Deployment Agent Service"), this fails to address the root cause. If you just disable services that trigger the problem, chances are it will rear its head again in the future in a marginally different guise. So it's worth understanding what's going wrong, because that leads to a better fix.

This problem arises when an application server wants total control of port 80. This conflicts with a feature of Windows that is designed to enable multiple processes to handle requests on port 80. It's entirely possible to have any number of processes all receiving HTTP requests on port 80, because Windows has a built-in HTTP dispatch mechanism. Each process can tell Windows which URLs it wants to handle.

However, if an application server totally ignores this, then you're back in the less flexible old-school sockets world where only one process can receive requests destined for any particular port.

That may be fine - if you really don't want anything other than a particular process handling HTTP request on port 80, then it becomes tolerable to use an application server that fails to support the more flexible mechanisms offered by Windows. (And some popular app servers have this limitation. E.g., AFAIK, Tomcat is incapable of playing well with others, and insists on having port 80 all to itself. So if you're using someone else's app server, it may well be impractical to adapt it to use the preferred mechanism.)

Windows attempts to accommodate such inflexible services by not binding its dispatch mechanism to port 80 until something actively asks for that. (This is why you won't necessarily see a problem initially, but can run into this issue after some sort of update or config change.) But relying on this is not a very solid solution - you're essentially trusting to luck that nothing attempts to listen under port 80 before your app server launches. (There are various reasons a process might speculatively attempt to register for certain URLs on port 80, and back off if it's not allowed.)

So if you want one service to have exclusive access to port 80, you'd better tell Windows. It's not really good enough to attempt to switch off all services that might try to use the usual port sharing mechanism, because it's difficult to be confident that you've found all of them. (Particularly when Windows updates seem to change what's on by default.) It's probably good practice to disable the ones you know about, but it's best to approach this from both ends: disable services you don't want, and also ensure that it's not possible for ones you didn't know about to trip you up.

By default HTTP.SYS (the underlying port sharing HTTP dispatch mechanism in Windows) is able to listen on all addresses. But you can tell it not to. This page shows one way to do that: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/

That is a relatively light way to do it, because it still enables listening on localhost for IPv6. It just frees up IPv4 port 80. You could take it further with more specialized config. (You could even disable HTTP.SYS entirely, but that might break things using ports other than 80, so it may cause problems.)

But whatever you do, the point is to ensure that HTTP.SYS doesn't attempt to listen on port 80 on the IP address you care about. Once you've done that, you don't need to worry about disabling services, nor do you need to worry about other changes re-introducing the problem. If you've ensured that the endpoint you need is effectively out of bounds for port sharing, then you should find that the system process stops binding to it.