Recently I developed the habit of killing processes with

fuser -k -n tcp $PORT

which can hardly kill the wrong process. I prefer this over fiddling with a pidfile that may or may not be still there or may or may not contain the correct pid (OK, I am a bit dramatic here :-)

Yet the typical stop script I stumble over still uses a pidfile.

Am I missing an important feature of the pidfile approach or a misfeature of the fuser approach. My best guess is that fuser is not available. Though judging by search engine results, bsd, debian, suse, centos, aix, solaris all seem to have it.


The fuser command option -n <file|udp|tcp>is Linux-specific, while the PID-file-based solution is traditional across many Unix variants, and so guaranteed to be very portable.

And in Debian at least, the fuser command is in psmisc package, which has been designated "optional", and so it cannot be expected to always be present for all systems.


There are two potential issues with this approach that come to mind beyond what telcoM mentioned, and they both have to do with a socket option called SO_REUSEPORT.

This socket option allows multiple processes (all of which have to set the option) to bind to the same port and offload the load balancing of connections traditionally done by a master process to the kernel.

The two potential issues that come from this are:

  • For servers that use process-based parallelism (NGinx for example) and use this option, the PID's that are connected to the socket will usually be children of the main process, and not the main process itself. In such a situation, your fuser approach will kill all the children, but not send any signal to the main process, which may not terminate the service at all (if the main process just restarts the children), or might result in it being shut down in a manner that causes problems (the code may assume that the child process dying indicates a fatal error, and use a different exit path than it would if the main process had instead received the signal itself).

  • This might kill other programs than what you want. Such a case is not very likely to be a bad thing (about the only 'other' programs you could kill are things that are probably malware), but it is worht considering.

  • The "kill send to wrong process" was actually the reason I started using fuser :-) I came across too many start scripts that recorded the pid of a parent process that I could kill, leaving the child processes running and blocking the port. Good to keep in mind that it could be the other way round too. – Harald Aug 29 '18 at 10:16
  • @Harald The other option is to just use a process supervisor like monit (or systemd), and tell that to kill the process. The most reliable way on UNIX to make sure you terminate the right process is to be it's direct ancestor (or use cgroups if you're on Linux). – Austin Hemmelgarn Aug 29 '18 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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