Recently we learned how to identify processes on our system. Obtaining the process ID or PID of a process gives us a unique identifier that we can use to manage the process in one way or another. Once we know the ID of a process we can begin to do magical things like setting the priority or even kill the process, both of which are super helpful when you have a process that has gone rogue and is eating up CPU.
Generally speaking, the tools we’re going to use in this article should already be on your system if you are running a UNIX-like operating system, like Linux or macOS.
Some of the commands we’ll be issuing will be destructive in nature.
Because my process IDs won’t be the same as your process IDs, they will be omitted from all of the examples. In place of the process ID, you will see
When adjusting priority or killing a command, you do need to have permission to do so. If you happen to not have permission to manipulate a particular process on your system, because it’s owned by another user or root, or because it’s a higher priority than your account can interact with, you can prepend the commands with
sudo and be off to the races!
Alligator.io Recommends ⤵👉 Fullstack Advanced React & GraphQL by Wes Bos
Adjusting Process Priority
Process priority is in reference to how important the system thinks the process is, and the kernel will adjust how the process is scheduled in relation to other processes to reflect the level of importance.
This priority is referred to as niceness, and the higher the nice value, the less nice the process is.
Yes, you read that correctly. Similar to golf scoring, where a lower score is better, a lower nice value means the process is actually nicer.
nice value ranges from
20. The range is dependent on the system.
For brand new processes, you can simply use the
nice command to start the command with a specific niceness. Starting an extremely nice process looks like this:
$ nice -n -19 /your/nice/command
That’s great for brand new processes, but what about processes that are already running?
That’s where knowing our process ID comes in handy. Let’s start a long running process in the background, which will spit back the process’s ID:
$ sleep 86400 &
Knowing the PID of the process, we can use that to make this process extremely naughty (err… less nice):
$ renice 20 :PID
renice it will let you know what the old and new priority are.
To check the current priority of other processes, you can run the
htop command and search for the PID in question or you could simply run
ps with the right arguments:
$ ps -o ni :PID
Sending signals to a running process is how we communicate with them.
We can sends signals to reload a daemon’s configuration and child processes send signals to their parent to let them know they have ended.
Modern Linux distributions offer a lot of other tools for sending signals to applications that take a lot of the guesswork out of what you’re doing.
They wrap the signals up in nice little restart and reload
systemd scripts and you’re good to go.
That’s all well and good, but sometimes we need to get closer to the metal to deal with processes that are out of control.
When that’s the case, there’s one signal that stands tall amongst the rest.
It’s the signal to
kill, which can work on even the most stubborn processes.
Killing processes, especially processes that have stopped responding and not respecting the rules of the road can still be killed with the
killing a command will send a
TERM signal to the process and it will attempt to shut itself down gracefully.
This is the parenting equivalent of asking your child if they think they should clean there room instead of of just telling them to freakin’ do it.
Nothing wrong with graceful shutdowns of applications, but it’s only great if the process hasn’t gone off the rails.
The more brutal way to
kill a process is a
kill -9. Passing in the
kill to send a
SIGKILL signal that will stop the process in it’s tracks.
Knowing the process ID, we can pass it to the command:
$ kill -9 :PID
Even if you don’t know the process ID, and your system supports it, you can use the
pkill command. It’s the same as
kill but accepts a process name instead of an ID:
$ pkill -9 /some/rogue/command
Both of the aforementioned commands are intended to work on individual processes. If you’d like to kill all of the processes of a particular name, you can use the
$ killall /some/other/command
Keep in mind this sends a
TERM signal and not a
SIGKILL command. I find this one to be better suited for killing processes on my local machine than on my server.
If you’ve ever made any macOS internal configuration tweaks to the Dock, you’re probably familiar with
killall as it makes it easy to restart your Dock’s process without a reboot.