Process_information

The process information shown for each connection includes the process ID (Pid), the name of the executed process and optionally the executed command (View/Command).

Not all connections will display process information (not running as root is the most common reason). For a some connections the displayed process information is less reliable (connections in the TIME_WAIT state are the most common case). See the technical section for details.

Columns:

• Pid: shows the process ID for the application that is using that connection on your computer. The process ID is used to uniquely identify instances of applications you start. If you start an application multiple times you may have more processes for that application.
• Program: shows the name of the application as known by the operating system. This is usually the public application name. There are exceptions. For example, 'Net Activity Viewer' has the program name 'netactview'.
• Command: shows the command used to start the application that uses the connection. Some processes modify their startup command to show a descriptive string or for various technical reasons.

---

Technical details

Inode number:

Netactview determines the process information starting from the socket inode number that is associated with the file descriptor. Note that the current wikipedia article on inodes is not relevant for the socket (man 7 socket) inode numbers. The socket inode numbers are a generalization of the file system inodes concept.

Connection tracking:

The socket inode number is also used as part of the connection identification when tracking the connection from one refresh to another. As the inode is not always available, the networking attributes form the main identification information for the connection (protocol, local address, local port, remote address and remote port).

Connection tracking is needed in order to enable a smooth refresh. Without tracking the whole list of connections would have to be replaced at each refresh.

Connections without process information:

Not all connections will show a process. Possible reasons are:

• If you use netactview without root rights you won't see the process information for the sockets (connections) created by processes executed as root. In this case, the inode number is usually available but the processes are not accessible in order to match this information.
• The linux kernel does not have an inode number for some sockets. Most of the time, for user space sockets, it is related with the fact that the socket is in a state that is not associated with a process. For example, TCP sockets before accept() and after close(). Example states: TIME_WAIT, FIN-WAIT-1, FIN-WAIT-2, CLOSING, LAST-ACK.
• Kernel space only sockets don't have an associated user space process. They can have an inode number, but don't have the process file descriptor. Kernel space sockets are very rare for TCP or UDP (2015-03) (possible example: iSCSI).

Connections with partial process information:

Some sockets are shared by multiple processes. A socket sharing technique is used by some web server software to better handle a large load. Normally, multiple instances of the same application work together to offer a service on the shared socket port. This situation is not common on a desktop for TCP or UDP sockets (2015-03). Netactview 0.7 will display a hint in the interface when there is more than one process (application instance) for a socket.

Connection tracking issues:

When a connection changes the state to TIME_WAIT, or any other state that does not have an inode number, netactview will continue to track the connection by its networking identification (protocol, addresses and ports). The process information is remembered in the new state. The networking identification is generally reliable, but there are some edge cases where it does not work.

The refreshed list (the snapshot) of connections is always displaying the correct list of active network sockets (active = not CLOSED; the networking information is correct; since 0.6.4). In some edge cases, for states that do not have an inode number, the remembered process matching may be wrong for some of the displayed sockets. In the same kind of edge cases if you follow the connection from one refresh to another the connection updates may be wrong (ex: updated instead of delete and new). Netactview 0.7 will improve the connection tracking algorithm to make the edge cases rarer and less problematic. It will also display notes in the interface when the process information is unsure.

Example issues:

• One situation where the networking identification has a higher probability to go wrong is a manual refresh at a large time interval. For connection states without an inode number, an old connection that was actually closed may be updated with the information of a newer one that is identical from a networking perspective. Instead of updating, the correct behavior would be to show the old connection as closed and highlight the new connection as new. If the old connection has process information and the new one is in the TIME_WAIT state, the process information is kept for the updated connection, and it may appear that the old connection is just closing, while it may have been closed for hours. This situation is not likely to happen on automatic refresh because the ephemeral ports are not reused immediately and connections are typically done from an ephemeral port to known service port.
• For a long enough refresh interval, problems similar with the above have some highly theoretical chance to happen even if the inode number is present for both the old and the new socket. The inode numbers are incremented up to a maximum value after which the they are recycled. On a very busy 32 bit server the recycle interval for socket inode numbers may be as low as a few weeks (32 bit servers are still popular on virtual machines; 2015-03). On a 64 bit server the recycle interval is billion times the 32 bit one.
• Another situation where the networking identification does not work is when connections with identical networking attributes are simultaneously created on purpose for various technical reasons. Most such usages do have an inode number all the time and netactview handles them without issues (since 0.6.4).

Inode number status for frequent states (mind the quotes):

• Listening TCP sockets (LISTEN) "always" have an inode number
• ESTABLISHED TCP connections "almost always" have an inode number (there is a short time before connection accept() when the connection does not yet have an inode number, which is more frequently visible on busy servers)
• TIME_WAIT TCP connections don't have an inode number, and the associated process information (same for the other states after close(): FIN-WAIT-1, FIN-WAIT-2, CLOSING, LAST-ACK)
• UDP sockets "always" have an inode number
• The quotes for "always" are related to the fact this may not be true for some kernel only sockets in custom kernel level network services and protocols implementations. There are custom patches for the linux kernel networking code and the main kernel does make large conceptual changes from time to time. The main kernel maintains backward compatibility with the documented concepts and API, but the details in this paragraph are not an explicitly documented guarantee. Also, because of the complexity of the kernel implementation some not documented details may be missed.

Netactview tries to rely only on what is explicitly documented by the kernel and system libraries for the core functionality. But some important features, like proper refresh, are more reliable in practice if knowledge about the kernel implementation is used.