Right now I'm on a million-hour train ride from New York to Montreal.
So I'm looking at the output of
strace because, uh,
cool, and it is teaching me some things about how the command line
use all the time work.
strace does is capture every single system call that gets
called when executing a program. System calls are the interface
between userspace programs and the kernel, so looking at the output
strace is a fun way to understand how Linux works, and what's
really involved in running a program.
killall! I ran
strace killall ruby1.9.1 2> killall-log.
This starts with
Every time you run a program,
execve gets called to start, so
execve will always be the first line.
Then this happens A WHOLE BUNCH OF TIMES:
with different PIDs.
What's going on here is that it goes through every PID. To find the
PIDs, it opens the
/proc directory. There's a directory in
for each PID.
The system call that does this is:
openat(AT_FDCWD, "/proc", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
Once it's done that, then it iterates through all the PIDs, opens
/proc/$PID/stat, and checks to see if the process has the right
name. The kernel isn't involved in seeing whether or not the process
has the right name, so we don't see that in the
Once it finds a PID that it wants to kill, it runs something like
to kill it. SIGTERM isn't a very serious killing-y signal -- it's
signal 15, and processes can ignore it or save their state before they
stop. If you run
killall -9, it will sent
SIGKILL to all the
matching processes and it will kill them dead.
This is really neat! I never thought of
killall as having to do an
exhaustive search through all PIDs before, but it makes sense.
After all of that, if there was something to kill, the only thing left
man 2 exit_group tells me that this exits all
threads in a process, and that this system call is called at the end
.of every process
If we run
killall blah, and there was no
"blah" process to kill,
instead we see:
because it needs to write "no process found" to stderr.
I have learned a couple of new things, from people's responses to this post!
If you want to see the library calls instead of the system calls, and
want to see where it does the string comparisons, you can use
python3 and killing it looks like:
And you can attach
ptrace to an already-running process
to see what it's up to. @zbrdge said
that he sometimes uses it to see which files Apache is accessing
during a HTTP request.