If you're a Linux guy/girl and you someday end up in charge of a Solaris box, just remember that killall acts very differently!
I almost think this is one of those "rights of passage" -- that everybody must do this at least once. You'll learn it the hard way but then you'll never forget...
Kinda like many years ago when I was (new to Cisco gear and) making changes to a firewall ruleset -- remotely -- and decided to take a shortcut because I was supposed to go meet friends and so I was in a hurry.
Never done this myself, but have done worse really. I was working at Sun a long time ago and we had a big shared development server. Being familiar with linux killall I suggested to my boss that he use killall instead of killing processes one by one. So he tried it out. Whole team had to wait quite a while for the server to restart. :-)
Random trivial apropos killall: The killall utility in FreeBSD had one of my all-time "favourite" bugs, prompting me to write this commit message in 2004:
Serial murderers shouldn't commit suicide. (killall should
avoid killing itself.)
I learned that on UNIX System V machines such as Solaris, killall ignores parameters and just tries to kill everything [1]. Maybe it's better to use pkill on GNU/Linux instead.
It survives in Linux as killall5 (the 5 being a reference to System V Unix). It's used during shutdown to send SIGTERM to all processes, then SIGKILL to kill off any stragglers.
Strace gives you a quick, higher level view of what is actually happening, which is sometimes much more useful than slogging through the source code of something.
Reading code has its place and tracing code has its place. I have difficulty understanding nontrivial codebases without some amount of tracing. In this case you chose to present the source for a FreeBSD/OS X version of killall when OP is running Linux.
ltrace is also pretty neat; it shows library calls (as opposed to system calls) - so you should be able to see the missing "strcmp()"s alluded to in the article.
What are the anonymous 4096 byte allocations before every read? I would think that killall would read /proc/{pid}/stat directly into a stack buffer, especially if the reads are only 1024 bytes.
I had a quick look. There are 6 calls to malloc in the killall program and several calls to functions like asprintf which will allocate. See my other post for source.
I get the best out of it by knowing about its -f option, and the fact that the program htop is like top but crazier, and there you can press "s" to jump to a paged strace view of any process you can control.
strace is one of my favourite tools. I don't need it that often, but it's comforting to know that it's there. Documentation can lie or just not answer my question, the source code might be unavailable or unreadable, but if I have a question that strace can answer, I can rely on it to answer.
It's one of the things I miss on OS X. dtruss isn't as powerful, and dtrace seems like it might be more powerful but I have no idea how to use it.
> ltrace is a debugging utility in Linux, used to display the calls a userland application makes to shared libraries.
This is useful because strace can completely ignore the information you really want. OTOH, ltrace doesn't provide information that's as pretty as what strace shows, because ltrace doesn't know as much about the functions it's showing you. This means arguments passed as pointers will be shown as pointer values, functions will occasionally be shown as taking the wrong number of arguments, and enum values will be shown as ints.
ltrace also can't show function calls to functions in statically-linked libraries, because it hooks into the dynamic loading mechanism.
I almost think this is one of those "rights of passage" -- that everybody must do this at least once. You'll learn it the hard way but then you'll never forget...
Kinda like many years ago when I was (new to Cisco gear and) making changes to a firewall ruleset -- remotely -- and decided to take a shortcut because I was supposed to go meet friends and so I was in a hurry.