Getting Started with Linux: Novells Guide to CompTIAs Linux Course 3060

1
Getting Started with Linux Novells Guide to
CompTIAs Linux (Course 3060)

• Section 8
• Processes, Jobs, and Runlevels

2
Objectives

• Understand Processes and Jobs
• View Processes from the GUI and the Command-Line
  Interface
• Manage Jobs and Processes
• Understand Runlevel
• Schedule Tasks

3
Understand Processes and Jobs

• To understand processes and jobs, you need to
  know the following
• Process Definitions
• Jobs and Processes

4
Process Definitions

• These terms are used to describe Linux processes
• Program structured set of commands stored in an
  executable file on a Linux file system
• Process program running in memory and on the CPU
• User process process launched by a user that
  runs from a terminal
• PID unique ID assigned to every process as it
  begins
• Child process process started by another process
• Parent process process that starts other
  processes
• PPID PID of the parent process of current process

5
Process Definitions (continued)
6
Jobs and Processes

• Each process is identified using a unique PID
• In Linux, you use a job ID to refer to processes
  started from an interactive shell
• In bash, jobs returns all processes that have
  been started from that shell and run in the
  background
• All jobs have a PID, but not all processes have a
  usable job ID
• PID 1 always belongs to the init process
• When the maximum process number has been reached,
  the next process is allocated the lowest
  available number (such as PID 7494)
• After one process has ended, its number again
  becomes available

7
View Processes from the GUI
Click to sort processes
Click to end a process
8
View Processes from the Command-Line Interface

• To view processes, you can use
• ps use to see running processes
• pstree displays a list of processes in the form
  of a tree structure
• pstree -up less
• lsof use to see which files are opened by
  processes
• top use to find out how much computing time
  processes use

9
View Processes from the Command-Line Interface
ps (continued)
10
View Processes from the Command-Line Interface
top
11
View Processes from the Command-Line Interface
top (continued)
12
Control Processes

• To control processes, you have to know how to
• Control Processes Using Signals
• Prioritize Processes

13
Control Processes Using Signals

• When a process receives a signal it can
• Capture the signal and react to it
• Ignore it if no function exists for handling that
  signal
• Processes do not have control over the following
  signals as they are handled by the kernel
• kill -SIGKILL or kill -9
• kill -STOP or kill -19
• kill 18734 or killall xeyes
• kill -SIGKILL PID or kill -9 PID
• For the kernel to forward the signal to a
  process, it must be sent by the owner of the
  process or by root

14
Control Processes Using Signals (continued)
15
Exercise 8-1 Control Processes from the GUI and
the Command Line

• If the system seems to react sluggishly, it is
  helpful to be able to find out the likely cause
• Various commands available for this purpose,
  graphical as well as based on the command line
• The purpose of this exercise is to familiarize
  you with some of the available tools

16
Prioritize Processes

• Linux distributes available computing time
  equitably
• NI column in top list contains nice value of
  process
• Values -20 (high) to 19 (low) default is 0
  (neutral)
• Only root can start a process with negative nice
  value
• Use renice to change nice value of a running
  process
• renice 5 1712 (only root can reduce the nice
  value)

17
Exercise 8-2 Manage Linux Processes and Services

• Processes can run with different priorities,
  leaving more (or less) resources for other
  processes
• Processes can run in the foreground or in the
  background, independently from their priority
• The purpose of this exercise is to show you how
  you can influence the priorities of different
  processes

18
Understand Runlevel

• In this objective, you learn the following about
  runlevels
• The init Program
• The Runlevels
• init Configuration File (/etc/inittab)
• init Directories and Scripts

19
The init Program

• The system is initialized by /sbin/init
• Controls booting up and shutting down of system
• signal 9 (SIGKILL) has no effect on init
• Main configuration file is /etc/inittab
• Determines what happens in the individual
  runlevels
• Entries indicate various scripts to be started
  scripts are located in /etc/init.d/ (SLES 9) or
  /etc/rc.d/init.d/
• In other distributions, /etc/rc.d/rc.local is run
  by init after all other initialization is
  complete
• Use to add commands for your environment

20
The Runlevels (continued)
21
The Runlevels (continued)

• Switch to another runlevel using init init 3
• Useful if you encounter problems caused by a
  particular service
• Switch to a lower runlevel to repair the service
• If GUI freezes, press Ctrl Alt Backspace to
  restart X
• Or, switch to a text console (Ctrl Alt F1),
  and as root issue init 3 and then init 5
• To shutdown or reboot system init 0 or init 6
• It is better to use commands in Table 8-10
• shutdown 5 The new hard drive has arrived
• shutdown -c

22
The Runlevels (continued)
23
Exercise 8-3 Work with Runlevels

• There is rarely a reason to change the runlevel
• The main reason is usually some maintenance work
• The purpose of this exercise is to teach you how
  to change runlevels

24
init Directories and Scripts (continued)
25
Schedule Tasks

• Most SLES 9 administrators and regular users find
  that they need to complete certain tasks
  regularly on a running system (such as updating a
  database or backing up data)
• You can automate these jobs in Linux by doing the
  following
• Schedule a Job (cron)
• Run a Job One Time Only (at)

26
Schedule a Job (cron)

• You can schedule jobs to be run on a regular
  basis by using the service cron (/usr/sbin/cron)
• Service checks once a minute to see if jobs have
  been defined for the current time
• By default, the service should be activated
• A crontab file contains the list of jobs
• A crontab exists for the entire system as well as
  for each user defined on the system

27
System Jobs

• You control system jobs with the file
  /etc/crontab
• The cron jobs that are defined here after
  installation run the scripts contained in Table
  8-12
• Do not delete lines from crontab added at
  installation
• Jobs are run later if they could not be run at
  the specified time
• /var/spool/cron/lastrun/

28
User Jobs

• To allow users to configure cron jobs, use
• /var/spool/cron/allow
• /var/spool/cron/deny
• By default, contains entries like guest and gast
• The jobs of a user are in /var/spool/cron/tabs/use
  r
• These files belong to root
• Use crontab to edit them

29
User Jobs (continued)
30
User Jobs (continued)

• Each line in a file defines a job
• /10 8-17 1-5 fetchmail mailserver
• From Monday to Friday, every 10 minutes between
  800 A.M.-500 P.M., fetchmail mailserver is
  run
• For system jobs, specify the user with
  permissions to run it, by entering its name
  between the time details and the name of the
  command

31
Exercise 8-5 Schedule Jobs with cron and at

• Scheduling jobs with cron is a very common task
• It can make system administration much easier to
  have certain regular tasks like backups run
  automatically outside working hours
• at is very handy for one-time tasks
• The purpose of this exercise is for you to use
  the available tools for scheduling tasks
• In this exercise, you do the following
• Part I Schedule Jobs with at
• Part II Schedule Jobs with cron

32
Summary

• Processes are programs executing on the system
• Every process has a PID, a PPID, and can possibly
  start an unlimited number of child processes
• The first process loaded by the kernel is the
  init, which always has a PID of 1
• Background processes have a job ID that you can
  use to control their execution
• You can view processes within a desktop
  environment by using the KDE System Guard, or at
  a command prompt by using the ps, pstree, lsof,
  and top commands

33
Summary (continued)

• The KDE System Guard and the kill, killall, and
  top commands can be used to stop processes by
  sending them signals
• You can affect the priority of a process by
  changing its nice value
• nice allows user to set the priority of a program
  and run it
• A Linux system is categorized using runlevels

34
Summary (continued)

• The init daemon is responsible for loading and
  unloading daemons, using the file /etc/inittab
• /etc/inittab runs scripts that start with S
  (start) or K (kill) in the /etc/init.d/rc.d when
  changing runlevels
• You can view your current runlevel using the
  runlevel command, and force the init daemon to
  change runlevels using the init command
• Commands may be scheduled to run at a later time
  using the at daemon
• To schedule tasks to occur regularly in the
  future, you must use the cron daemon to create a
  crontab