Lab 6 - Processes and Services
Overview
At any given moment, there are anywhere from dozens to thousands of process running on a Unix system. The large majority of these processes, called daemons, run in the background. Daemons are crucial to having a usable system and provide much of a system’s core functionality, including the graphics server, sound server, and networking services to name a few.
Today we’ll explore these background processes and create some of our own! Make sure the following exercises are executed on your VM unless explicitly specified otherwise. Make sure to answer the questions on Gradescope as you work through the lab!
Which processes are running on my system?
Open up a terminal and run the ps command. You should see something like this:
PID TTY TIME CMD
3371 pts/2 00:00:00 zsh
3416 pts/2 00:00:00 ps
Now open up another terminal and run sleep 1000 &, which start a sleeping process in the background. Then run ps. It should look like:
~
❯ sleep 100 &
[1] 3726
~
❯ ps
PID TTY TIME CMD
3371 pts/2 00:00:00 zsh
3726 pts/2 00:00:00 sleep
3752 pts/2 00:00:00 ps
In the first terminal run ps again. You should notice that the sleep process is not showing up, even though the thousand seconds haven’t expired. (Exercise 1) Why do you think this behavior occurs (hint: TTY column)?
We can get the process to display on the first terminal by running ps -u, which displays all the processes running as your user. Notice the PID column; each process has a unique ID assigned to it by the kernel. One thing we can do with this PID is send signals to the process. sleep 1000 is pretty useless, so go ahead and kill it – kill 3726 (substitute 3726 with whatever PID ps outputted for you).
The most common use of ps is to run ps -ef to see all the processes running on the system. Run ps -e and ps -f independently to see how the flags work together.
htop
Make sure htop is installed by running sudo apt install htop. Now, open up a terminal and run the htop command. htop can be thought of as a more extensive version of ps -ef, whereby process stats are updated in real-time.
First press <F2>, scroll down to Display options, and check “Hide userland process threads.” We won’t be dealing with those in this lab.
Now open up another terminal and SSH into your VM. Run the command yes. It uses a lot of resources as it prints a continuous stream of y’s. (Exercise 2) What resource specifically does the yes command exhaust? If you are having trouble finding this, press < to choose which resource to order processes by. Make sure to quit out of yes (^C) once you are finished.
The process hierarchy
Run htop once more. This time click <F5> to enter Tree View. You should see a visual representation of the process hierarchy on your system, with everything stemming from /sbin/init (systemd).
For curious students that are interested in seeing a more extensive process hierarchy on a large system, you are encouraged to run htop on the OCF server tsunami. Let us know of any cool processes that you find!
Orphan processes
Open a second terminal and ssh to your VM. Now run sleep 1000 &. You should see this new process pop into your htop session on your first terminal. If not, press <F3> and search for “sleep.” (Exercise 3) What is its parent?
Select this parent and press <F9> to kill it. Send the SIGTERM signal. The sleep process now has init as its new parent, which is PID 1. What you just did is manually orphan a process; when that happens said process is subsequently re-parented by the init process.
Now go through the same steps again. This time, send the parent a SIGHUP (hangup) signal. Can you still find the sleep process? When SIGHUP is sent to a parent shell, the parent subsequently sends hangup signals to any child processes before terminating; all processes that receive SIGHUP from a parent shell will terminate – this is one way to avoid creating orphan processes.
If you are interested in learning about the different signals, run man 7 signal. Note that you can run man man for an explanation about the different manual section numbers.
Cron
So much infrastructure in the computing world relies on scheduled processes. This is the job of the cron daemon, an automatic process scheduler. For example, at the OCF, we use a cron job that runs every thirty minutes to keep our servers and desktops updated via puppet.
Process scheduling is defined in a crontab file. Each line in the file represents a different job. A line consists of a time descriptor, typically a sequence of 5 terms separated by spaces, and a command to be run at that time.
For example, the line:
5 12 2 8 * echo "It is 12:05 on August 2nd" >> $HOME/crontest.txt
would append “It is 12:05 on August 2nd” to a file in your home directory at 12:05 on August 2nd. You can find an interactive editor to help you with the time descriptors at crontab.guru!
To get a feel for the cron scheduler, we’re going to write a basic cron job.
(Exercise 4) Open the cron editor by running crontab -e (if the editor of your choice isn’t being launched, set the EDITOR environment variable), which will create a crontab for your user. Below is a sample task. Put this in your crontab:
* * * * * date +"\%T" >> $HOME/timestamps.txt
Right now this runs every minute. Modify it to run every five minutes and make a note of the line you wrote. Then, quit out of the editor.
If you get stuck, visit crontab.guru! (Seriously, it’s a lifesaver!)
Job Control
For this section of the lab you will need to get the necessary code from GitHub:
git clone https://github.com/0xcf/decal-labs.git
If you already have the code run git pull in your decal-labs directory.
Now enter the b6 directory in the decal-labs repository and split your terminal with the multiplexer of your choice (I recommend tmux). In one pane run ./job.sh > ~/count and in the other run less +F ~/count. You should see the less command increments every half a second or so. Now run Ctrl+Z in the pane with the job.sh command. This will suspend the process. (Exercise 5) What happens when you suspend the job command?
Now, let’s resume our suspended process. Since we only have one job, we can just run bg. (Exercise 6) What happens after running the bg command?
Now let’s bring our job to the foreground. First run jobs -l. You should see both the job number (in brackets) and the pid of the job. We’ll bring the job to the foreground by running fg %i (where i is the number that showed up in the brackets when you ran jobs -l) and kill it using Ctrl+C. (Exercise 7) What is another way we can kill the job (Hint: kill also recognizes the % syntax)?
Exploration
Congratulations, you have completed the lab! This is just the tip of the iceberg when it comes to processes. If you want to learn more, here are some related topics you can look into.
Submission
Go to Gradescope for submission.