Now we're going to take a look at process management.
Process management is all about us in Linux because our services are tasks.
Everything we do and see on our Linux system is managed by processes.
We're going to be taking a look at the ps command,
the pgrep command, and the pkill command.
So this is all about directly managing our processes.
But we can also get a view of our system performance using top,
and we can tune the performance, how much priority is assigned to our processes,
using the nice command and the renice command.
But we're going to begin by taking a look at our processes in Linux and
the /proc directory and those associated commands,
ps, pgrep, and pkill.
In Linux, everything that is being executed,
whether it's a service or whether it's a command that we are executing,
exists as a process, and as such, if I move into the /proc directory,
we're able to see, as I run the listing,
the numbered directories that we see towards the left of the
screen all represent running processes.
If I move back to my home directory and clear the screen,
if I go through and take a look at my current process,
so that's a special variable we can access through $$,
and we can see the Bash shell that I'm currently echoing,
echo is an in‑built command to Bash, is process ID 1044.
Now I can move into that directory by using cd/proc,
and this is a command that's going to work for you
irrelevant of your Bash process.
But if we go then into proc/$$, we move into,
then, when I look at my pwd/proc/1044,
the directory representing my current running process,
and then I can go through and just run the ls command,
and we can see files and directories representing resources that are in use.
Now in general, as users or administrators,
we probably don't need to become too familiar with the /proc directory,
because we can always check our process status with the process status,
or ps, command.
If I just go through and run ps,
we're looking at all processes that are running within my current terminal.
So I've got the Bash shell, and obviously, I've just executed the ps command.
I can go through and then do a ps and ‑p to look at a process,
and then $$, and then I'm able to go through and see,
well, a little bit of information,
but not much more information than we could see before.
But I can also go through and take a look at a long listing.
Now the long listing, as you can see, gives us much more information,
including things such as the process status,
the parent process ID, and priority values,
such as the priority and nice value.
If you want to see this in a more friendly format,
though, we can use the full listing and within our full listing,
we translate the user id into the username.
The parent process ID, of course, is the process ID that launched the Bash shell.
Now, if we wanted to go through and look at all of our processes,
we could see the pstree command.
If I go through and take a look at that,
though, we don't have that command on our system at the moment.
That's not a problem, though, because I can go through and do a yum and provides,
and if I go through and take a look for usr/bin/pstree,
we can see there that it is coming from the ps MIsc package,
so I can do a sudo and yum install psmisc.
And we include the ‑y so it doesn't prompt to run
the install; it just runs ahead.
And now we can go through and run our pstree command,
so we see all of the processes in their hierarchy,
where systemd is the top of our tree.
Generally,
we're using the ps command to then send it through to grep
so we can look for running processes.
If we start by taking a look at the sleep command,
if I go sleep and 5, I don't get my command prompt back for 5 seconds,
so we're emulating a longer running command here.
Now obviously, if it was longer than 5 seconds,
it could be a little bit of a pain, but if we go through and,
say, put 5000 seconds, and then we can background our task,
so the process runs in the background just by adding ampersand at the end.
I can run this a few times so we've got many sleep processes running.
Rather than using the ps command and piping it through to grep,
if I want to look for those, I can use pgrep and sleep,
so we can list all of those processes that are running the sleep command.
If we want a little bit more information,
we can actually then go through and run ps ‑,
let's say, a full listing,
for the processes that are generated from the
output of the complete last command.
That's my!!, hit the enter, and we can see then that that expands to pgrep sleep,
and were able then to see the information in more detail.
Very often, we're looking for these processes so we can terminate the processes.
I can do that, again, very simply now using pkill,
where we're then searching for processes that start or have sleep in their name,
and we can then terminate.
If I don't specify the signal,
we send a ‑term through to the pkill command to those processes.
If we go through and, say, start a sleep process up again,
if we went through and did a pkill ‑9 or ‑kill,
they're all the same thing, we're sending the kill process through.
So rather than asking for it to be terminated, we are actually shutting the process down ourselves.