Find (and kill) old processes

33,463

Solution 1

YOu can do this with a combination of ps , awk and kill:

ps -eo pid,etime,comm

Gives you a three column output, with the process PID, the elapsed time since the process started, and the command name, without arguments. The elapsed time looks like one of these:

mm:ss
hh:mm:ss
d-hh:mm:ss

Since you want processes that have been running for more than a week, you would look for lines matching that third pattern. You can use awk to filter out the processes by running time and by command name, like this:

ps -eo pid,etime,comm | awk '$2~/^7-/ && $3~/mycommand/ { print $1 }'

which will print the pids of all commands matching 'mycommand' which have been running for more than 7 days. Pipe that list into kill, and you're done:

ps -eo pid,etime,comm | awk '$2~/^7-/ && $3~/mycommand/ { print $1 }' | kill -9

Solution 2

killall --quiet --older-than 1w process_name

Solution 3

If you have a Python/Perl/Ruby script you want to kill, killall won't help you since killall will just look for "python" or "perl", it can't match the name of a specific script.

To kill all processes older than X seconds where any part of the full running command matches a string, you can run this as root:

MAX_SECONDS=43200
PROGRAM_THAT_NEEDS_TO_DIE=bad-python-script.py
ps -eo pid,etimes \
    | grep -v PID \
    | awk '$2>'$MAX_SECONDS'{ print $1 }' \
    | xargs --no-run-if-empty ps -f --pid \
    | grep $PROGRAM_THAT_NEEDS_TO_DIE \
    | awk '{ print $2 }' \
    | xargs --no-run-if-empty kill -9

Use ps to get a list of all processes (-e) and only output the pid and the elapsed number of seconds (-o pid,etimes).

grep -v PID to remove the header line.

Use awk to only select lines where the elapsed seconds are greater than 43200s (12 hours), and to strip out just the first column with the PIDs.

Pass the list of PIDs back to ps to get the full process listing.

Use grep to find the lines that contain the name of the script that you want to kill.

Use awk again to pull out the PID of the script.

If there are any processes found, kill them.

Solution 4

All the info you need can be grabbed from ps -ef. See the "STIME" column. Combine that with grep to sort out the processes you need. At that point, you can use cut to grab the pid of all the matching processes and pass those to kill.

Please let me know if you'd like more details on how to do this.

Share:
33,463

Related videos on Youtube

Ryaner
Author by

Ryaner

never ending interesting boringness

Updated on September 17, 2022

Comments

  • Ryaner
    Ryaner over 1 year

    Basically I need to be able scan the process tree and find processes that match a certain name and started running more than a week a go. Once I have them, I need to kill them. All the processes are still seen as in a running state by the system, just not using any system time. They'll usually sit forever in this state too.

    Ideally I'd like something similar to find, but for processes.

    System is Debian linux and this will be scripted and run by cron so I've no real issues with something large but understandable.

    • Chopper3
      Chopper3 over 14 years
      how are you going to differentiate between old-but-important processes and ones you're happy to kill?
  • Ryaner
    Ryaner over 14 years
    Nice one thanks. Completely forgot about the formatting options in ps.
  • hobodave
    hobodave over 13 years
    This doesn't show you processes running "more than 7 days". It shows you processes running between 7 days but less than 8 days.
  • hobodave
    hobodave over 13 years
    This doesn't work either. As-is it generates this warning, and no additional output: find: warning: you have specified the -maxdepth option after a non-option argument -user, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments. Moving -maxdepth to be the first output it returns no processes, and I am positive that many should match.
  • hobodave
    hobodave over 13 years
    I would like more details. The other answers are simply incorrect.
  • poige
    poige almost 12 years
    etimes is more handy — serverfault.com/a/393476/67675
  • Philipp Christoph
    Philipp Christoph about 11 years
    also why mtime not ctime if you're looking for the creation date of the dir? the dir could theoretically be modified if an additional child was created, which I wouldn't rule out (perhaps a newly loaded kernel module would extend sysfs in some way)
  • ezwrighter
    ezwrighter almost 6 years
    This works awesome on Ubuntu 16.04 and you can use with the -i (interactive) flag to test and make sure it's targeting the processes you think it should be.
  • Earl Ruby
    Earl Ruby almost 4 years
    Timestamps on the directories in /proc are not the times that the processes were created. You can have a process that was started days ago that has a pid entry with a current timestamp.
  • Earl Ruby
    Earl Ruby almost 4 years
    Timestamps on the directories in /proc are not the times that the processes were created. You can have a process that was started days ago that has a pid entry with a current timestamp. man find says that -ctime is "File's status was last changed n*24 hours ago." ctime is NOT "creation time". mtime Modification time: The last time when the file’s content was modified. atime Access time: The last time when the file was read. ctime Change time: The last time when the file (either its content or metadata, such as permissions) were modified.
  • Earl Ruby
    Earl Ruby almost 4 years
    -mtime Modification time: The last time when the file’s content was modified. -atime Access time: The last time when the file was read. -ctime Change time: The last time when the file (either its content or metadata, such as permissions) were modified.