Linux Exercise: Working with processes

Listing processes and system statistics

  1. Make a list of your processes.
    • $ ps
  2. Make a long list of all processes on the system.
    • $ ps aux
  3. Make a list of the process hierarchy on your system.
    • $ pstree
  4. Make a list of the process hierarchy on your system, including process ID numbers.
    • $ pstree -p
  5. Generate a 1-second summary of all CPU statistics.
    • $ sar 1
  6. Generate a 1-second summary of all IO statistics.
    • $ iostat 1
  7. Generate a 1-second summary of all memory statistics.
    • $ vmstat 1
  8. Generate a continuously refreshing list of system statistics and process details.
    • $ top
  9. Leave the top command running in a separate window. Start a new PuTTy or terminal window to perform the rest of this exercise. Occasionally glance at your top window to see what's happening on the system.

Working with process priorities

  1. Check whether the /usr/local/bin/busycpu program is installed. If it is, continue with the next step. If it is not, create your own busycpu program that just performs an empty loop.
    • $ which busycpu
      If you get a response "/usr/local/bin/busycpu", go to the next step. Otherwise, create a file ~/bin/busycpu with the following contents: 
      #!/bin/bash
while true
do
  :
done
      Save the file, and make it executable with chmod +x ~/bin/busycpu
  2. Wait for at least one other student to arrive at this step. The next steps only make sense if you have multiple busycpu programs competing for CPU time. If no other students are ready for the next steps (yet), ask your instructor to start a busycpu instance.
  3. Run the busycpu program. Look at your top window. How much CPU share does the program receive? What is the nice value?
    • $ busycpu
      The busycpu program should receive an equal share of the cpu, dependent on how many other busycpu programs are running. The nice value is zero.
  4. Stop the busycpu program with Ctrl-C. Start it again, but this time with a nice value of 10. How much CPU share does the program get?
    • Ctrl-C
    • $ nice busycpu
      The busycpu program should now receive a significantly lower portion of the CPU.
  5. Stop the busycpu program with Ctrl-C. Start it again, but this time with a nice value of 20. How much CPU share does the program get?
    • Ctrl-C
    • $ nice -n 20 busycpu
      The busycpu program should now receive an even lower portion of the CPU. The nice value is 19, which is the highest value that can be assigned.
  6. Stop the busycpu program with Ctrl-C. Start it again without a nice value. Try to manipulate the nice value from your top window, and with the renice command. (For the latter you'll have to open a third SSH window.)
    • Ctrl-C
    • $ busycpu
    • In the top window, use the r command to renice a process.
    • $ renice 15 <PID>
      You can only increase the nice value of a process, not decrease it. Also, you can only renice your own processes, not those owned by other users.
  7. Stop all busycpu processes.

Working with foreground and background processes

  1. Start a single busycpu process in the foreground.
    • $ busycpu
  2. Halt the busycpu process. Look at the output of the jobs command and your top window. Is busycpu running?
    • Ctrl-Z
    • $ jobs
      Your busycpu process is now stopped.
  3. Let your busycpu process continue in the background. Look at the output of the jobs command and your top window. Is busycpu running?
    • $ bg 1
    • $ jobs
      Your busycpu process is now running again.
  4. Start a second busycpu process. Make sure it goes to the background immediately. Look at the output of the jobs command and your top window. Is this busycpu running?
    • $ busycpu &
    • $ jobs
      Both busycpu processes are now running.
  5. Pull your first busycpu process to the foreground and stop it with Ctrl-C. Does this work?
    • $ fg 1
    • Ctrl-C
    • $ jobs
      Your first busycpu process was terminated. The second one is still running.
  6. Start a new busycpu process in the background again.
    • $ busycpu &
    • $ jobs
  7. Start a vi session in the foreground. Stop the session and see if you can pull it to the foreground again. Does this work?
    • $ vi testfile
    • (Within vi:) Ctrl-Z
    • $ jobs
      Your vi session is now stopped.
    • $ fg 4
      Your vi session is now running in the foreground again.

Working with signals and traps

  1. Check whether the /usr/local/bin/nasty program is installed. If it is not, ask your instructor to install it. The code is also available here.
    • $ which nasty
  2. Take a look at the code for the nasty program. What signals are trapped?
    • $ cat /usr/local/bin/nasty
      The program traps the signals 2, 3, 9 and 15.
  3. Start the nasty program.
    • $ nasty
  4. Try to stop the nasty program with Ctrl-C. What happens?
    • Ctrl-C
      The nasty program receives the signal that is generated by Ctrl-C (signal #2). It reacts to this by running the signal handler. As the signal handler does not contain an exit, nasty will continue running after having executed the signal handler.
  5. Try to stp the nasty program again, this time with Ctrl-\. What happens?
    • Ctrl-\
      The same things happens: The signal is trapped and causes the signal handler to run.
  6. Open or use another terminal window. From this window, find the PID of your nasty process. Kill it with the kill command. What happens?
    • $ ps aux | grep nasty
    • $ kill <PID>
      The same thing happens: nasty cannot be killed with a regular kill command, as the default signal (#15) is trapped by the signal handler.
  7. Now try to kill nasty with the kill -9 command. What happens?
    • $ kill -9 <PID>
      This time you could kill the nasty process. The reason is that the signal handler for signal #9 cannot be overwritten.

Return codes

  1. Take a look at the manual page of the grep command. Look for the EXIT STATUS section. What are the potential exit statuses that grep uses?
    • $ man grep
  2. Look for the "root" entry in the /etc/passwd file with grep. Immediately afterwards, check the exit status. Does this fit with what was written in the manual page?
    • $ grep root /etc/passwd
    • $ echo $?
  3. Look for the "toor" entry in the /etc/passwd file with grep. Immediately afterwards, check the exit status. Does this fit with what was written in the manual page?
    • $ grep toor /etc/passwd
    • $ echo $?
  4. Look for the "root" entry in the /etc/password file with grep. Immediately afterwards, check the exit status. Does this fit with what was written in the manual page?
    • $ grep root /etc/password
    • $ echo $?
  5. Look for the "root" entry in the /etc/passwd file. If it's there, then a text "root is here" should be printed.
    • $ grep root /etc/passwd && echo "root is here"
  6. Look for the "toor" entry in the /etc/passwd file. If it's not there, then a text "toor is not here" should be printed.
    • $ grep toor /etc/passwd || echo "toor is not here"
End of exercise