Whenever we launch a program, it lives as a so called process on the operating system
that is until it finishes its job or it's closed.
For example, when we run a command such as LS, a short lived process gets created.
The process for LS displays the directory's content.
And as soon as the job is finished, the process is closed.
Other processes though have a long life.
The SSH daemon is a good example as
it's usually running continuously on a Linux server.
The commonly used command to inspect processes is PS
and PS is a bit weird because it supports two kinds of syntaxes for its options,
dash A in a command like PS dash A
uses the Unix syntax
in a command like PS space A. However, the BSD syntax is used
and PS
A has an entirely different effect than PS space A.
The dash A and A options are not equivalent.
If we use PS without any options, we'll see a result like this
by default,
PS will only show us processes launched in our current terminal window or session.
But we're interested in all processes on the system
to make PS show them all, we need to combine three options A X and U,
the A X combination makes PS display all processes,
the U option lists processes in the so called user oriented format.
This adds useful columns to the output or we can see things like memory and CPU usage.
It also shows us which user each process belongs to.
That's why the most often used command to see all processes on a Linux system
is PS dash A UX.
You can remember it if you think of the word auxiliary
and if you forget it, you can get a quick refresh with man PS.
And if you scroll one or two pages down,
you'll find the examples section showing you the most commonly used PS commands.
Let's analyze this PS
AUX
output briefly
percent CPU shows us how much percent of the CPU is currently in use by this process.
100% means the entire capacity of one CPU core is used.
So we might see numbers like 150 here,
meaning one full core is used but also 50% of the capacity of a second core
percent memory shows us how much percent of the total memory this uses
start, shows us the time at which the process was started
or the date. If the process was not started today,
time shows us how much CPU time is used during the process' lifetime.
So even if a process started six hours ago,
it might have only used three seconds of CPU time during its lifetime.
The rest of the time is spent in a sleeping state using 0% of the CPU
to get one second of time here.
The process needs to use 100% of one CPU core for an entire second.
If it would use 50% of one CPU core for 10 seconds,
it would get around five seconds of time recorded in this column.
Finally, in the command column,
we can see the exact command that was used including options to start this process.
Now,
another interesting thing we see in this output is
that some processes are wrapped between square brackets.
These are kernel processes running inside a privileged area of the Linux kernel.
We usually don't need to interact with
these as the kernel manages them internally and
will only deal with normal processes running outside
this privileged area called the user space.
These are the ones that are not wrapped between square brackets
but PS only shows us the state of processes
at the exact moment when we execute the command.
If we want to continuously watch what's going on, we can use a different command
in the name of that command is talk
by default,
top will constantly reorder processes in this list
and show the most CPU intensive ones.
At the top.
We can navigate through this output with the arrow keys and page up or page down
to quit. We press Q
but how about filtering results.
We can also narrow down our list and only look for specific processes.
If we know the P ID or process identifier number of a process,
we can use it in a command like this.
In this case, one is the P
I.
And if we want to see the same kind of output as before with CPU and memory usage,
we can use the U option again to display the user oriented format.
If we want to see the processes that have been started by the user Jeremy,
we pass the username after the dash uppercase U option.
And again, if we want the user oriented format,
we will add in the lower case U to this command.
Now, sometimes we will want to explore processes that have a specific name
to search for any process that contains the word this log in its name. For instance,
we can use P grap or process grap.
The
A option here which means all makes P grep also
display the command in which the process was started.
So we see a line like this.
The first field is the P id or process id. In this case, it's 1084.
What follows it is the command that started this process.
Now in Linux,
there's this concept of process niceness that is
how nice a process is to other processes.
The niceness value can be a number between negative 2019.
The lower the number, the less nice. It is.
In other words, a lower number means a higher priority.
Consider process A with a nice value of negative 20
process B with a nice value of 19.
If both of these are running at the same time,
we need to use all CPU resources available.
Process A will be very little available for process B
A might use up CPU 95 to 99% of the time.
While B will get very little CPU time only when there's something left to spare,
we'll want important processes to have higher priority,
which means we will assign them lower nice values.
There are two ways this can be done.
First at launch time, we can launch a command with a preset. Nice value.
The syntax is nice dash N followed by the nice value and then the command
to assign a nice value of 11 to the bash command. We can run this
nice dash N 11 bash. Our previous PS A UX command doesn't show nice values,
but we can use the L option that turns on BS
D long format output which includes columns for nice values.
We'll see these in the N I column.
If we want to see nice values for all processes, we just add the A X options.
Our nice dash N 11 bash command started a new bash shell
and we can see that the Pslax command inherited the nice value of a Rash shell.
That's because all processes inherit the niceness of their parent process.
The one that launched them
to see which processes are parents for other processes, we can add the f option
which stands for forest display because it shows
us treelike branches for this child parent relationship.
We can clearly see how our previous bash shell started a second bash shell.
And this in turn started the PS FA X command.
We can clearly see here how our previous bash shell started a second
bash shell and this in turn started the PS FA X command.
If we also want to see CPU usage, memory usage and the columns we're used to,
we can throw the U option in here.
The order of the FA UX letters is not important.
OK? Let's exit this second bash shell with exit.
Now, a regular user can only assign nice values between zero and 19
to assign lower values for higher priority. We need to use root privileges.
So this command
will not work. As you can see here. Permission is denied to set it to negative 12.
But this will
and we can confirm the value is set
with PSL A
and there's our bash shell
with the minus 12 nice value.
So let's exit our bash shell once again.
Now, the problem with the command pseudo nice dash N dash 12 bash
is that it also started our bash shell as the root user.
But what if we want our process to run under our regular user,
we can do it this way. First, we launch the program as usual,
we'll start yet another bash shell and imagine that this is some
utility that we want to give very high CPU usage priority to.
Now, in the PS forest view, we can identify the
pid of this second bath shell
right here.
And we see that this has a pid of 12238,
we can readjust the current nice value of
an existing process to another value with re
nice. And we use this syntax
Reni
followed by the new nice value followed by the pid of the process.
So to change it from its current default value of zero to something like seven,
we can enter this
and we'll get this confirmation message where it
shows the old priority and the new priority.
And if we take another look with Pslax,
we see that this is indeed now seven.
But what if we try to lower it to six?
We find out that regular users cannot lower the
nice value of a process that it currently has.
So we can't change anything below the current niceness of seven.
We can only make it 89, 10 or larger but not 65 or lower.
So this will work.
But to lower it,
we once again need root privileges since only root can lower process niceness.
Awesome.
So let's exit our second best show.
Linux has this concept of sending processes so-called signals.
These are like high priority messages that tell the process, hey,
stop what you're doing.
We have the special request for you,
but an application can only act on a specific signal
if it was programmed to respond to that signal.
The only exceptions are signals like sigstop and sigkill.
These cannot be ignored by the process.
When they receive sigstop, their execution will be paused until sig
or continue
is received.
So when they receive sigkill,
they will be immediately terminated without even getting
a chance to save their current work.
A sigkill
is usually only set as a last resort when the
program is not responding and it can't be closed.
In any other way,
we can see a list of signals that we can send with the dash L or list option.
When we choose a signal to send, we can use a name from this list.
So we could type Sigup,
but we can also admit the SIG prefix if we want and just type in Hup.
So Sigup and hup
are equivalent.
Let's find out the pid of our SSH daemon.
Now we can press Q to quit this view
and we have a pid of 1457 in this case.
Now let's send it the sighup signal
to do that. We type in kill.
Now let's send it the SIGUP signal to do that. We type in kill
dash
the
H
1457.
Now we get operation not permitted
that's because the SSH D process is running under the root user
as a regular user, we can only send signals to processes owned by our current user.
And of course, root is the Exception
and it can send signals to any process, its own processes,
but also processes owned by others.
So we need to turn our command into this.
The SSH daemon is programmed to respond to this in a certain way.
We can see what it did. If we check out its service status again.
As we can see here, when it receives SIGUP,
it's programmed to reload its configuration file and restart.
Now in the table displayed here, we can see that each signal has a number before it.
So to send the Sigkill command, we can use three different variants.
We can do
kill
the kill,
kill dash, kill without the sig
or kill
nine.
It's also worth noting if we don't specify a signal name,
the Sigterm
signal will be sent by default.
So kill 1752 will send Sigterm to the process of P ID 1752.
Sigterm tells the program to gracefully shut down.
It has a chance to save its work and close down. Normally
with kill, we send a signal to a process with a certain P ID number.
But another command PKILL lets us send signals to
processes with a certain name instead of API D.
For example,
let's say we want to send sigkill to all
processes that have a name containing the word bash.
Before we send that signal, we can explore what processes would receive it.
So we don't send it to the wrong ones.
We can type in pgrep
a
bash. And if we're happy with the result,
this abruptly ends our SSH session since the bash cell is forcefully closed.
So we'll have to log back in
now backgrounding and foregrounding processes, pausing and exiting
some commands can take a long time to finish their job.
Let's simulate this with the sleep command.
This will simply wait for 100 and 80 seconds until it exits
way too long.
Now, we can tell a program to quit whatever it's doing by pressing control C
Now, let's see another scenario.
Let's start editing some file.
But in the middle of this editing,
maybe we want to do something else and leave our editor open.
We can pause our current application and return to the terminal with control Z.
Now we can do something else.
Now, as you can see, we're back to our prompt. We're not in Vim anymore,
but we can return to our PASD
app with this command
FG
FG stands for foreground.
That is bring the app back to the foreground back to the focus in our terminal
and we can type escape
then quit
to quit our Vim editor.
It's worth noting that control C and Controlz won't work for any program,
but they work for most of them.
It's also worth noting when a program paused with control Z,
it does not make any progress with its work.
It's entirely frozen.
So if we want a program to do its work in the background, we use the Ampersand
symbol.
For example,
this is called backgrounding a command.
An example when this would be useful, imagine we want to back up 500 gig of data.
And let's say this would take 30 minutes.
We don't want to wait for 30 minutes until the backup command finishes.
So we can background it,
it will do its job for 30 minutes.
But in that time, we can continue to use the terminal and enter other commands.
No need to wait for the entire backup to finish
to check if we have any programs running in the background or paused,
we can type in jobs.
And as we can see, we have a job running here.
If we want to return to our backgrounded command,
we type in FG one
because our backgrounded command has the idea of one.
But now we brought our sleep 300 command back to the foreground and we're stuck.
Now, we can press control Z
to pause it and get back to the command-line. But this is problematic.
The app is now paused.
If this would be the backup job, it wouldn't be making any progress
when we could take a look at our active jobs again.
And we can see the imaginary backup job is stopped
to make it resume progress. We can use the BG or background command
and now jobs
will show us that this is running
and the backup is completing.
Sometimes we want to see what files or directories a process is currently using.
First. Let's find the P ID of our bash shell.
Our P ID in this case is 13536.
And if you're following along, of course, it'll be different
now to see what files or directories our bash process with P ID 13536 is using.
We would type in this
and this shows all the files and directories that this process is using.
Now later on,
we might want to explore other processes and
we might get output that looks like this.
We can also specify the path to a file or
directory to see if any process is currently using it.
And there it is.
This way we make sure we're getting the full picture
and this concludes our demo on diagnosing and managing processes.