I think you see killall in how-to's because by default it requires the precise process name, whereas pkill does basic pattern matching. Thus, killall is safer for users to blindly copy and paste.
Pkill and killall both have distinguishing options. Killall has a flag to match by process age, pkill has a flag to only kill processes on a given tty. Etcetera ad nauseum. Neither is better, they just have different specialties.
I see from their man pages that killall comes from the psmisc package, which has several process managing utilities, but notably doesn't contain ps. It's the procps package that has ps, top, kill, and pkill (among others). I'd wager procps didn't originally have pkill, so psmisc scratched an itch and came up with killall.
The pkill/pgrep man page says they were introduced in Solaris 7. As you mention, jgbelacqua, Solaris's killall was not the utility psmisc provides, thus Solaris probably only had the procps package. Someone wanted a pattern matching process tool, thus pkill and pgrep. Whether it was developed by the procps dev or added in afterwards, I don't know. Regardless, it made it in and became part of *nixes everywhere.
More sources:
I am going to state a application-specific possibility.
When you use killall program, a SIGTERM (signal 15) is sent to the program. The usual response to SIGTERM is that the program would exit gracefully.
Now as the SIGTERM is catchable, a program can have a signal handler for SIGTERM that would do some task upon receiving the first SIGTERM (first killall) and return to a state where the second SIGTERM would just terminate it (default action). This is highly dependent on the developer of the program of course and not a general case.
Best Answer
1. `killall` already nice (SIGTERM)
killallby default sendsSIGTERM. This is already the nice approach that leaves applications the chance to clean up after themselves. The "go die already, right now!" approach is to send aSIGKILLsignal, which requires specifying that as an option tokillall. From The GNU C Library: Termination Signals:2. System Monitor's "End process" equally nice (SIGTERM, too)
You link to a question about GNOME System Monitor. That does use
SIGTERMfor its "End process" action too (and I realise I am contradicting the answer to that question). You can find it in the source code to verify yourself:data/menus.ui:
The 15 here is the signal number. Signal 15 is
SIGTERM. And System Monitor has usedSIGTERMwell before that other question was asked and answered.Technical addendum (in response to a comment)
Looking through the Github representation of
git blame, here are the changes that have been made to how the signals are spelt out in the source code of GNOME System Monitor:383007f2 24 Jul 2013 Replaced duplicated code for sending signals with GAction parameters
0e766b2d 18 Jul 2013 Port process popup menu to GAction
97674c79 3 Oct 2012 Get rid of ProcData structure
38c5296c 3 Jul 2011 Make indentation uniform across source files.
None of these changed from
SIGQUITtoSIGTERM, and that last one was from before the linked question was asked.