Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

root can kill any program run by any user. Is it possible for a user to kill another user's program without using sudo, etc.?

Example: How can make user foo kill program x which is run by user bar?

share|improve this question
Is there any reason why you want to do this? – Nils Oct 7 '11 at 20:48
There are reasons I would want to do this. Memory is a limited resource on the shared cluster I use and sometimes people leave memory-eating processes paused for a long time. I would enjoy being able to kill those processes without asking them to. – Joshua Jun 25 '14 at 16:37
I found my answer right here on stackexchange unix.stackexchange.com/questions/185903/… bash is interactive, in the absence of any traps, it ignores SIGTERM I was running bash in interactive mode – Dwayne Nov 24 '15 at 20:31
up vote 8 down vote accepted

This is from the kill(2) manpage:

For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process. In the case of SIGCONT it suffices when the send‐ ing and receiving processes belong to the same session.

So essentially, under normal circumstances, if you are not root (and have no way to become root or that other user, via sudo or setuid programs), you cannot kill another user's process.

share|improve this answer

It's only possible for root and bar to kill a process owned by bar. Sudo/setuid programs change foo's privileges to those of root.

share|improve this answer

See Gilles answer at Why does bash ignore SIGTERM?

First, this isn't specific to bash. ATT ksh, dash and zsh behave the same way: they ignore SIGTERM and SIGQUIT during command line edition; as for mksh, it also doesn't quit but treats them like SIGINT.

Both the ksh manual and the bash manual justify ignoring SIGTERM in these terms:

so that kill 0 does not kill an interactive shell

kill 0 kills all processes in the process group that the shell is in¹. In a nutshell, the process group consists of all the processes running in the foreground on a terminal, or all the processes in a background or suspended job.

share|improve this answer

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.