One of the idioms often used to check if process is running is to use kill -s 0 $pid.

My question is, does it have any upsides over using [[ -e /proc/$pid ]] construct?

The script I'm writing is both Linux and bash specific.


I would prefer kill -s 0 pid vs testing /proc/pid as the former is portable, being specified by POSIX. Even if your script is targeting Linux, there is still a (very slight) risk for /proc to be unmounted for some reason.

| improve this answer | |
  • While the portability argument is moot as the script is Linux specific and won't be ported to other Unices (for one, it interfaces with kernel using /sys already). The possibility for /proc being unmounted is valid, even if unlikely. So I'm marking this answer as the accepted one. – Hubert Kario Nov 26 '13 at 10:51
  • 1
    I generally agree that kill -s 0 pid is the right way to go, but note that there are cases where it's not appropriate. Primarily when you don't have permissions to signal the process (non-root or whatnot). – Patrick Nov 26 '13 at 13:22
  • @Patrick, I agree about the privilege requirement issue. I guess though that when someone test if a process is running, he usually has the privilege to restart it which means either the process belongs to him or he is root. – jlliagre Nov 26 '13 at 13:48
  • Neither of these methods tell you whether there is such a process, only whether or not there were such a process at the instant in the past when you performed the test. – Johan Nov 27 '13 at 13:03
  • @Johan That looks to me more a philosophical point than a technical one. Anything you do/test/observe is instantly moved in the past anyway. – jlliagre Nov 27 '13 at 13:09

I would generally use a command such as kill over reading content directly from /proc. The upside is that a tool such as kill will return status codes (think $?) if it was successful, or not, and should in theory already have any API related things included, when it's dealing with /proc content vs. rolling it yourself.

Additionally using dedicated commands makes for better portability of your code across the various Unixes. /proc is not ubiquitous on other Unixes such as Solaris and AIX.


Test process to kill.

$ sleep 10 &
[1] 11639

Now we kill it.

$ kill 11639
[1]+  Terminated              sleep 10

Were we successful?

$ echo $?

A zero means we were successful. Anything else, we could handle it in different ways. With reading the /proc directly, we're left in a bit of a quandary.

Same situation, we're attempting to kill a non-existent process.

$ kill 61234
bash: kill: (61234) - No such process

We get feedback about it.

$ echo $?

What else?

You may also want to investigate using pkill and pgrep too if you'd rather kill or look for a process by name, rather than $pid. But it depends ultimately on what you're trying to do.

| improve this answer | |
  • 1
    Well, [[ -e /proc/pid ]] also returns a status code, after all. – Chris Down Nov 25 '13 at 20:01
  • @ChrisDown - true, but I would expect a much richer range of statuses using kill vs. reading /proc is my general point. – slm Nov 25 '13 at 20:20
  • @slm, the expected status doesn't need to be anything but true or false (and perhaps permission denied in restrictive environments). You might be missing the -s 0 part of the question which is not about killing a process but just testing its presence. – jlliagre Nov 25 '13 at 21:48
  • @jlliagre - yes I should've mentioned that I was aware of kill -0 ... That still doesn't change which method would be the more appropriate to use. – slm Nov 25 '13 at 22:29

There is a major difference between kill -s 0 $pid and [ -e /proc/$pid ]. The latter tests whether there is a process (or zombie) with this PID. The former only matches processes (or zombies) to which you can send a signal, i.e. the process's real or saved UID must be the same as the UID of the shell you're running this from (unless the shell is running as root, in which case there is no difference).

Which one to use depends on whether you want to match other users' processes.

kill -s 0 $pid is very portable (it's POSIX-compliant). Testing for /proc/$pid doesn't work on BSD unices as they don't have /proc; a portable way of achieving the same effect is ps -p $pid >/dev/null 2>/dev/null.

| improve this answer | |
  • Yet, on linux ps would go straight ahead to querying /proc/$pid so one may as well save the overhead of forking a whole new process. – oakad Nov 26 '13 at 2:55
  • 1
    @user16653: One: ps is a tool to be used by user, not in scripts, querying /proc in such use case and being racy is not a problem. Two: kill is a bash builtin, there is no forking involved in either command. – Hubert Kario Nov 26 '13 at 10:50

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.