Kill process by fuser instead of pidfile?

Question

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.

Answer 1

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.

Answer 2

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.