Why does this executable still execute after I deleted it

executablefilesnfs

I deleted the executable, so why is it still running?

root@raspberrypi:/test# ls -la
total 11096
drwxrwxrwx  2 pi pi     4096 Mar 12 18:26 .
drwxrwxr-x 11 pi pi     4096 Feb 28 13:50 ..
-rwxrw-rw-  1 pi pi    12149 Feb 28 13:00 .cproject
-rwxrw-rw-  1 pi pi     3183 Mar 12 18:26 main.cpp
-rwxrw-rw-  1 pi pi     2169 Feb 28 14:28 main.cpp~
-rwxrw-rw-  1 pi pi     1862 Feb 28 13:20 original.cpp
-rwxrw-rw-  1 pi pi      984 Feb 28 13:09 .project
-rwxrw-rw-  1 pi pi 11323309 Jan 28 12:54 teatro.png
root@raspberrypi:/test# ./testedfb 
running...

–update:

Some time later (after I tried to compile again, but there's an error, and the executable was not created) the behavior changed to:

root@raspberrypi:/test# ./testedfb 
bash: ./testedfb: No such file or directory

But I'm still curious; why was it was running?

–update (2):

Just happened again, and I did the test:

root@raspberrypi:/test# killall -9 testedfb
testedfb: no process found
root@raspberrypi:/test# ./testedfb 
running...

And it still runs…

I'm on a Raspberry Pi's Bash.

–update (3):

It just happened the oposite now, the file was there, but it was not found:

root@raspberrypi:/test# ./testedfb 
bash: ./testedfb: No such file or directory
root@raspberrypi:/test# ls
main.cpp  main.cpp~  original.cpp  teatro.png  testedfb

(and on the next attempt it did run)

Maybe it's the NFS (this folder is mounted) that is too slow to update?
(thanks @derobert for asking about the filesystem) – this would answer this second case, not the first one, as I cannot see the executable, but still I can execute it… (and looks like the process is not running too)

Best Answer

To run a program, it is opened by the kernel (or its interpreter). As long as it is running, the file is kept open.

Deleting a file that is open in Unix deletes its name from the disk, the file itself is only deleted when it is closed.

Add the above two, and you see that the running program continues to use its program file, and that one will be deleted only when the program exits.

Related Solutions

Bash Error – Cannot Execute Binary File

The message cannot execute binary file has nothing to do with terminals (I wonder what led you to think that — and I recommend avoiding making such assumptions in a question, as they tend to drown your actual problem in a mess of red herrings). In fact, it's bash's way of expressing ENOEXEC (more commonly expressed as exec format error.

First, make sure you didn't accidentally try to run this executable as a script. If you wrote . ./executable, this tells bash to execute ./executable in the same environment as the calling script (as opposed to a separate process). That can't be done if the file is not a script.

Otherwise, this message means that ./executable is not in a format that the kernel recognizes. I don't have any definite guess as to what is happening though. If you can run the script on that same machine by invoking it in a different way, it can't just be a corrupt file or a file for the wrong architecture (it might be that, but there's more to it). I wonder if there could be a difference in the way the target boots (perhaps a race condition).

Here's a list of additional data that may help:

Output of file …/executable on server B.
Some information about the target, such as the output of uname -a if it's unix-like.
Check that the target sees the same file contents each time: run cksum ./executable or md5sum ./executable or whatever method you have on the target just before yet-another-bash-script invokes ./executable. Check that the results are the same in the Hudson invocation, in your successful manual invocation and on server B.
Add set -x at the top of yet-another-bash-script (just below the #!/bin/bash line). This will produce a trace of everything the script does. Compare the traces and report any difference or oddity.
Describe how the target is booting when you run the scripts manually and when Hudson is involved. It could be that the target is booted differently and some loadable module that provides the support for the format of ./executable doesn't get loaded (or is not loaded yet) in the Hudson invocations. You might want to use set -x in other scripts to help you there, and inspect the boot logs from the target.

Bash – Why can’t root execute when executable bits are not set

In short, because the execute bit is considered special; if it's not set at all, then the file is considered to be not an executable and thus can't be executed.

However, if even ONE of the execute bits is set, root can and will execute it.

Observe:

caleburn: ~/ >cat hello.sh
#!/bin/sh

echo "Hello!"

caleburn: ~/ >chmod 000 hello.sh
caleburn: ~/ >./hello.sh
-bash: ./hello.sh: Permission denied
caleburn: ~/ >sudo ./hello.sh 
sudo: ./hello.sh: command not found

caleburn: ~/ >chmod 100 hello.sh
caleburn: ~/ >./hello.sh
/bin/sh: ./hello.sh: Permission denied
caleburn: ~/ >sudo ./hello.sh 
Hello!

Best Answer

Related Solutions

Bash Error – Cannot Execute Binary File

Bash – Why can’t root execute when executable bits are not set

Related Question