If you send a signal to a process, that process gets killed. I wonder how the rumor that killing a process also kills other processes got started, it seems particularly counter-intuitive.
There are, however, ways to kill more than one process. But you won't be sending a signal to one process. You can kill a whole process group by sending a signal to -1234 where 1234 is the PGID (process group ID), which is the PID of the process group leader. When you run a pipeline, the whole pipeline starts out as a process group (the applications may change this by calling setpgid or setpgrp).
When you start processes in the background (foo &), they are in their own process group. Process groups are used to manage access to the terminal; normally only the foreground process group has access to the terminal. The background jobs remain in the same session, but there's no facility to kill a whole session or even to enumerate the process groups or processes in a session, so that doesn't help much.
When you close a terminal, the kernel sends the signal SIGHUP to all processes that have it as their controlling terminal. These processes form a session, but not all sessions have a controlling terminal. For your project, one possibility is therefore to start all the processes in their own terminal, created by script, screen, etc. Kill the terminal emulator process to kill the contained processes (assuming they haven't seceded with setsid).
You can provide more isolation by running the processes as their own user, who doesn't do anything else. Then it's easy to kill all the processes: run kill (the system call or the utility) as that user and use -1 as the PID argument to kill, meaning “all of that user's processes”.
You can provide even more isolation, but with considerably more setup by running the contained processes in an actual container.
netstat
There's a process there, your userid just isn't privy to seeing what it is. This is a layer of protection provided by lsof that's keeping you from seeing this. Simply re-run the command but prefix it using the sudo command instead.
$ sudo netstat -antlp | grep 45136
There's even a warning about this in the output of lsof at the top.
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
Example
$ netstat -antlp | grep 0:111
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
$ sudo netstat -antlp | grep 0:111
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1248/rpcbind
ss
If you're not having any luck with netstat perhaps ss will do. You'll still need to use sudo, and the output can be a little bit more cryptic.
Example
$ ss -apn|grep :111
LISTEN 0 128 :::111 :::*
LISTEN 0 128 *:111 *:*
$ sudo ss -apn|grep :111
LISTEN 0 128 :::111 :::* users:(("rpcbind",1248,11))
LISTEN 0 128 *:111 *:* users:(("rpcbind",1248,8))
Process ID still not there?
There are instances where there simply isn't a PID associated to the TCP port in use. You can read about NFS, in @derobert's answer, which is one of them. There are others. I have instances where I'm using ssh tunnels to connect back to services such as IMAP. These are showing up without a process ID too.
In any case you can use a more verbose form of netstat which might shed additional light on what process is ultimately using a TCP port.
$ netstat --program --numeric-hosts --numeric-ports --extend
Example
$ netstat --program --numeric-hosts --numeric-ports --extend |grep -- '-' | head -10
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 192.168.1.103:936 192.168.1.3:60526 ESTABLISHED root 160024310 -
tcp 0 0 192.168.1.1:2049 192.168.1.3:841 ESTABLISHED sam 159941218 -
tcp 0 0 127.0.0.1:143 127.0.0.1:57443 ESTABLISHED dovecot 152567794 13093/imap-login
tcp 0 0 192.168.1.103:739 192.168.1.3:2049 ESTABLISHED root 160023970 -
tcp 0 0 192.168.1.103:34013 192.168.1.3:111 TIME_WAIT root 0 -
tcp 0 0 127.0.0.1:46110 127.0.0.1:783 TIME_WAIT root 0 -
tcp 0 0 192.168.1.102:54891 107.14.166.17:110 TIME_WAIT root 0 -
tcp 0 0 127.0.0.1:25 127.0.0.1:36565 TIME_WAIT root 0 -
tcp 0 0 192.168.1.1:2049 192.168.1.6:798 ESTABLISHED tammy 152555007 -
If you notice the output includes INODES so we could back track into the process using this info.
$ find -inum 152555007
Which will show you a file which might lead you to a process.
References
Best Answer
Found it!
To find the
screeninstance in which PID 351 is running, search the PID 351 environment for the string "STY=":Or using
ps(if screen session names don't contain space characters):