6

Is there any way to find out what I just killed?

$ ps -A -o pid,cmd | grep someApp | grep -v grep
2802 python someApp.py
$ sudo kill 2302
$

EDIT: To clarify, I need to know what PID 2302 was before I killed it. The ps line is to give context as to how I killed 2302 when I don't even know what it was.

dotancohen
  • 15,864

3 Answers3

8

There is no general way to know, but you may have clues.

You sent a TERM signal, not a KILL signal, so that left the program the opportunity to run a signal handler. It might not have died at all, or it might have left a log entry somewhere. Check whether the process is still running (ps 2302), and if not, check your system logs.

There is a log of all processes if you have process accounting enabled. This is available on Linux through GNU acct, but with most distributions the package is not installed by default. If process accounting is enabled, run lastcomm (you may need to be root) to see the recently killed processes (latest first). With lastcomm, only the command name is tracked, not the PID or the arguments; you'll have to figure out which process it is by circumstantial matching. Under Linux, lastcomm shows the date the process exited but only with a granularity of 1 minute, and there is an X flag after the command name if the command was killed by a signal.

GNU acct tracks more information, including the process ID, but the lastcomm command doesn't display it: you have to run dump-acct, which unfortunately does not indicate whether a command was killed by a signal.

dump-acct /var/log/account/pacct | awk -F '|' '$10 ~ / *2302($| )/'

There are other subsystems that can log processes, such as Linux's audit, but they are usually not configured to do so.

Gilles 'SO- stop being evil'
  • 829,060
  • Thanks, Gilles. This answer shows how to configure the system to in fact provide the information needed. – dotancohen Jan 26 '13 at 17:19
  • 1
    Note that process accounting, generally called BSD process accounting is available on many Unices, not only Linux. The accounting (logging) is done by the kernel, GNU acct or whatever tool is used to parse the kernel generated files, does not track information (the kernel does) – Stéphane Chazelas Jan 26 '13 at 21:03
4

There's no definitive way unless you used something to log every process spawned on your system (like auditing or process accounting).

Now, things you may want to try:

  • That process might be logging thing (via syslog or other) including its pid, so you could do a zgrep -w 2302 /var/log/**/*(.m-1) (zsh syntax) to try and identify it.
  • It or its parent might have logged something to report the death of that process, you could look at the files that have been modified since the kill, to see if they contain any clue (look at the .xsession-errors of every graphically logged in user, in /var/log again, look at the lsof -nP output to see if there are some entry looking like log files currently open...)...
  • If not too many processes are being spawned on that machine, look at pids close to 2302 and their start time. 2302 might have been a parent or child of them, or be related commands, it might give an indication of what user likely spawned it...
  • in case it was spawned in a terminal of some user, you could look if any modification time of any terminal device in /dev matches the time of the kill which could help you again narrow your search...
Stéphane Chazelas
  • 544,893
  • 1
    nice hints. I'd add : if it was a daemon, it could still have its pid file under /var/run (depending on the kill handling. 'kill -9' for example would not leave it time to take its pid file. Not sure about "kill" here, depends on how the daemon [if it was one] trap, or doesn't trap, it.) – Olivier Dulac Jan 25 '13 at 16:56
  • 1
    some ps allow a tree view (or a pstree command), helping in figuring out who the parent of this or that process is. In your case however it would only help if that process had "sister" process with a similar number and the same parent... quite unlikely – Olivier Dulac Jan 25 '13 at 16:58
3

No, there isn't. Not afterwards, that is.

But if you do a "ps -A > list" before the kill-command, you would have a file called list which contains a list of all processes which ran before killing that process.

Bonsi Scott
  • 2,513