Is this on Linux?
There are actually a few subtly different versions of the command name that are used by ps, killall, etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u; and 2) the short command name, which is what you get when you run ps without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here's a really trivial script that demonstrates the difference. I called it mycat:
#!/bin/sh
cat
After running it, here's the two different types of ps.
Firstly, without u:
$ ps -p 5290
PID TTY ... CMD
5290 pts/6 ... mycat
Secondly, with u:
$ ps u 5290
USER PID ... COMMAND
mikel 5290 ... /bin/sh /home/mikel/bin/mycat
Note how the second version starts with /bin/sh?
Now, as far as I can tell, killall actually reads /proc/<pid>/stat, and grabs the second word in between the parens as the command name, so that's really what you need to be specifying when you run killall. Logically, that should be the same as what ps without the u flag says, but it would be a good idea to check.
Things to check:
- what does
cat /proc/<pid>/stat say the command name is?
- what does
ps -e | grep db2 say the command name is?
- do
ps -e | grep db2 and ps au | grep db2 show the same command name?
Notes
If you're using other ps flags too, then you might find it simpler to use ps -o comm to see the short name and ps -o cmd to see the long name.
You also might find pkill a better alternative. In particular, pkill -f tries to match using the full command name, i.e. the command name as printed by ps u or ps -o cmd.
A tty is a native terminal device, the backend is either hardware or kernel emulated.
A pty (pseudo terminal device) is a terminal device which is emulated by an other program (example: xterm, screen, or ssh are such programs). A pts is the slave part of a pty.
(More info can be found in man pty.)
Short summary:
A pty is created by a process through posix_openpt() (which usually opens the special device /dev/ptmx), and is constituted by a pair of bidirectional character devices:
The master part, which is the file descriptor obtained by this process through this call, is used to emulate a terminal. After some initialization, the second part can be unlocked with unlockpt(), and the master is used to receive or send characters to this second part (slave).
The slave part, which is anchored in the filesystem as /dev/pts/x (the real name can be obtained by the master through ptsname() ) behaves like a native terminal device (/dev/ttyx). In most cases, a shell is started that uses it as a controlling terminal.
Best Answer
The behaviour you experience depends most likely on differences in the environment variable
$PATH. The$PATHis essentially a colon-separated list of directories, which are searched in order for a particular executable when a program is invoked using anexecoperating system call. The$PATHcan contain relative path components, typically.or an empty string, which both refer to the current working directory. If the current directory is part of$PATH, files in the current working directory can be executed by just their name, e.g.a.out. If the current directory is not in$PATH, one must specify a relative or absolute path to the executable, e.g../a.out.Having relative path components in
$PATHhas potential security implications as executables in directories earlier in$PATHovershadow executables in directories later in the list. Consider for example an attack on a system where the current working directory path.preceeds/binin$PATH. If an attacker manages to place a malicious script sharing a name with a commonly used system utility, for instancels, in the current directory (which typically is far easier that replacing binaries in root-owned/bin), the user will inadvertently invoke the malicious script when the intention is to invoke the systemls. Even if.is only appended at the end of$PATH, a user could be tricked to inadvertently invoke an executable in the current directory which shares a name with a common utility not found on that particular system. This is why it is common not to have relative path components as part of the default$PATH.