Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm running Xvfb on a FC8 Amazon EC2 image. On occasion Xvfb will crash (unable at the moment to find out the reason for the crash), and after crashing the TCP port will appear to be orphaned. I'm unable to get a PID to kill any process that may be using it.

I'm starting Xvfb with:

Xvfb :7 -screen 0 1024x768x24 &

Examples of what I'm working with are below, the Xvfb port is (was) 6007:

# netstat -ap 
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 *:ssh                       *:*                         LISTEN      1894/sshd           
tcp        0      0 *:6007                      *:*                         LISTEN      -                   
tcp        0    352 c-71-194-253-238.hsd1:51689 ESTABLISHED 2981/0              
udp        0      0 *:bootpc                    *:*                                     1817/dhclient       
udp        0      0 *:bootpc                    *:*                                     1463/dhclient       
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  2      [ ]         DGRAM                    871    668/udevd           @/org/kernel/udev/udevd
unix  2      [ ACC ]     STREAM     LISTENING     5385   1880/dbus-daemon    /var/run/dbus/system_bus_socket
unix  6      [ ]         DGRAM                    5353   1867/rsyslogd       /dev/log
unix  2      [ ]         DGRAM                    11861  2981/0              
unix  2      [ ]         DGRAM                    5461   1974/crond          
unix  2      [ ]         DGRAM                    5451   1904/console-kit-da 
unix  3      [ ]         STREAM     CONNECTED     5438   1880/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     5437   1904/console-kit-da 
unix  3      [ ]         STREAM     CONNECTED     5396   1880/dbus-daemon    
unix  3      [ ]         STREAM     CONNECTED     5395   1880/dbus-daemon    
unix  2      [ ]         DGRAM                    5361   1871/rklogd

# lsof -i
dhclient 1463 root    3u  IPv4   4704       UDP *:bootpc 
dhclient 1817 root    4u  IPv4   5173       UDP *:bootpc 
sshd     1894 root    3u  IPv4   5414       TCP *:ssh (LISTEN)
sshd     2981 root    3u  IPv4  11825       TCP ip-10-84-69-165.ec2.internal:ssh-> (ESTABLISHED)

Attempting to force the port closed with iptables doesn't seem to work either.

iptables -A INPUT -p tcp --dport 6007 -j DROP

I'm at a loss as to how to reclaim/free the port. From what I can tell, this port will remain in this state until the EC2 instance is shut down.

So, how can I close this port so I can restart Xvfb?

share|improve this question
What happens when you try to start a program that listens on port 6007, e.g. 'nc -l 6007'? Do you get a message that it is already in use? –  sciurus Mar 18 '11 at 21:50
Yes: # nc -l 6007 nc: Address already in use –  Jim Fiorato Mar 18 '11 at 22:14

2 Answers 2

up vote 1 down vote accepted

I did some more investigation of why Xvfb was failing, and there were several kernel panics on the server for several different processes.

Unable to handle kernel paging request at virtual address

When this kernel panic occurred on Xvfb, we'd find this situation described in the question, where the kernel has the port open and we're only able to release by rebooting the machine.

As I was investigating the kernel panic I came across this link:

As it turns out the kernel we were using (2.6.16-xenU) is now unstable on Amazon EC2 instances:

I changed the kernel we were using to and all seems to be well now.

This doesn't really answer the question as to how to free the open port, but I think with this kernel issue, that it was not possible to free that port without a reboot.

share|improve this answer
The link leads to weird flash game. –  Eduard Wirch Sep 25 '12 at 11:26

fuser -kn tcp 6007 run as root should kill whatever process has port 6007 open.

share|improve this answer
No luck withe fuser either. fuser -n tcp 6007 shows no processes on that port. –  Jim Fiorato Mar 19 '11 at 11:12
The only explanation I can think of is that the kernel must have port 6007 open, although I don't understand why. –  sciurus Mar 20 '11 at 22:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.