I have a xmms2d process running, but two possible executable files (in different directories, both in the executable path) that could have spawned it. I suspect that one of those is corrupted, because sometimes this program works and sometimes it doesn't. The process running now works, so I want to delete (or rename) the other one.

ps ax|grep "xmms" returns 8505 ? SLl 2:38 xmms2d -v without path information. Given the PID, could I find whether it was run from /usr/bin/xmms2d or /usr/local/bin/xmms2d?


  • 2
    ps -C xmms should make your grep obsolete. – user unknown Mar 3 '11 at 5:02
  • 1
    pgrep would do it too. – jlliagre Mar 3 '11 at 22:10

Try this:

ls -l /proc/8505/exe

Or if you don't want to parse the output of ls, just do:

readlink /proc/8505/exe


realpath /proc/8505/exe

If you are running Solaris, the way is slightly different from the Linux one suggested:

$ for i in $(pgrep bash)
  printf "%6d %s\n" $i $(readlink /proc/$i/path/a.out)
   577 /usr/bin/bash
 11247 /usr/bin/bash
 13921 /usr/bin/bash
 13992 /tmp/bash

Should you want to know the current working directory of running processes, you can use:

pwdx $(pgrep xmms)


$ pwdx $(pgrep ksh)
2904: /home/jlliagre
2906: /home/jlliagre
3844: /tmp
  • (deleted my comment as it no longer applied after your edit:) – Kjetil Jorgensen Apr 8 '11 at 17:53

I start mousepad from the shell:

mousepad & 
[1] 24289

check, where it comes from:

which mousepad 

start it with path:

/usr/bin/mousepad &

look via ps:

ps v -C mousepad 
24289 pts/3    S      0:00      3    62 85441 10964  1.0 mousepad
24292 pts/3    S      0:00      0    62 85433 10864  1.0 /usr/bin/mousepad

As we see, the one invoked without path is displayed without path, and started with the PATH, and therefore to be found by

which mousepad

Simple as that, isn't it? Wait! What if I start mousepad from the menu? Well, it might be specified with or without using the PATH settings. I tried. A normal start leads to a simple 'mousepad' in ps v -C. Since ~/bin is the first part of my PATH I create a dummy there, and, voila, the dummy is started from the menu.

But what if you start a program which deletes itself? Which will not find the deleted program and report a wrong one, if there is a second in the path.

So that's a race condition. If you know that your programs don't delete themselves or aren't moved while you're investigating their location, ps v -C NAME and which NAME should work pretty well.

  • Will this always work? Suppose I have an executable in two different directories and I run ./someexecutable in both? – apoorv020 Mar 3 '11 at 7:09
  • No, of course not, because both will show up as ./someexecutable or /bin/bash ./someexecutable – user unknown Mar 3 '11 at 13:44

Go ahead and delete both the files (without force -f option). The file that gets deleted is the one, that was not running !!

System executable file locking will not allow you to delete any file that is currently under execution.

  • Your answer doesn't provide an real answer to the question. – Risto Salminen Dec 12 '13 at 12:27
  • 4
    It is also wrong. You can delete running executables without issue. How do you think packages such as init, which are always running, get upgraded? You cannot modify a running executable. – Patrick Dec 12 '13 at 13:58
  • 1
    This is alarmingly wrong -- don't do this – Michael Mrozek Dec 12 '13 at 17:31

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.