Managing processes and services

1. How Linux handles processes 2. Managing running processes 3. Scheduling processes

1. Describe How Linux Handles Processes What exactly is a process? The heredity of Linux processes

What Exactly Is a Process? Processes defined Types of processes

Processes Defined For our purposes here, a process is a program that has been loaded from a long-term storage device, usually a hard disk drive, into system RAM and is currently being processed by the CPU on the motherboard. Many different types of programs can be executed to create a process. Linux operating system can run many processes “concurrently” on a single CPU. Depending on how your Linux system is being used, it may have only a few processes running at a given point in time or it may have hundreds of processes running concurrently.

The Linux operating system quickly switches between the various processes running on the CPU, making it appear as if the CPU is working on multiple processes concurrently. However, the CPU actually only executes a single process at a time. All other currently “running” processes wait in the background for their turn. The operating system maintains a schedule that determines when each process is allowed access to the CPU. This is called multitasking. Because the switching between processes happens so fast, it appears, to you and me at least, that the CPU is executing multiple processes at the same time.

Newer, dual-core CPUs can actually execute more than one process at a time. Because there are two cores within the CPU, one core can execute one process while the other core works on another.

Types of Processes Not all processes on your Linux system are the same. Some processes are created by the end user when he or she executes a command from the shell prompt or though the X Windows graphical interface. These processes are called user processes. User processes are usually associated with some kind of end-user program running on the system.

The heredity of Linux processes The parent/child relationship between processes The heredity of processes

The Parent/Child Relationship Between Processes

Whenever a process is created on a Linux system, it is assigned two resources: Process ID (PID) Number This is a number assigned to each process that uniquely identifies it on the system. Parent Process ID (PPID) Number parent process.

The Heredity of Processes

There really is a “grandparent” process that spawns all other processes. This is the init process. The kernel loads the init process automatically during bootup. The init process then launches child processes, such as a login shell, that in turn launch other processes, such as that used by the vi utility

2. Managing running processes Starting system processes Viewing running processes Prioritizing processes Managing foreground and background processes Ending a running process

Starting System Processes There are two basic ways to start a process on a Linux system. For a user process, you simply enter the command or script name at the shell prompt. For example, to run the vi program, you simply enter vi at the shell prompt.

For system processes, however, you use an init script. An init script is used by the init process to start processes on system boot. These scripts are stored in a specific directory on your Linux system. Which directory they are stored in depends on your Linux distribution. Most Linux distributions use one of two types of init scripts: System V Linux distributions that use System V init scripts store them in the /etc/rc.d directory. Within /etc/rc.d are a series of subdirectories named rc0.d through rc6.d BSD These scripts reside in the /etc/init.d directory. Within /etc/init.d are a series of directories named rc0.d through rc6.d

on a BSD-style system: /etc/init.d/script_name start | stop | restart on a System V–style system /etc/rc.d/init.d/script_name start | stop | restart ex: /etc/init.d/smb start /etc/init.d/smb stop /etc/init.d/smb restart on SUSE Linux, The syntax is rcscript_name start | stop | restart ex: rcsbm start

Viewing Running Processes Using top Using ps

Using top The following columns are used to display information about each process: PID The process ID of the process. USER The name of the user that owns the process. PR The priority assigned to the process. NI This is the nice value of the process. VIRT The amount of virtual memory used by the process.

RES The amount of physical RAM the process is using (its resident size) in kilobytes. SHR The amount of shared memory used by the process. S The status of the process. Possible values include:  D Uninterruptibly sleeping.  R Running.  S Sleeping.  T Traced or stopped.  Z Zombied.

%CPU The percentage of CPU time used by the process. %MEM The percentage of available physical RAM used by the process. TIME+ The total amount of CPU time the process has consumed since being started. COMMAND The name of the command that was entered to start the process.

Using ps The ps utility can be used to display running processes on your system. Unlike top, which displays processes dynamically, ps displays a snapshot of the current processes running.

The following information is displayed by default: PID The process ID of the process. TTY The name of the terminal session (shell) that the process is running within. TIME The amount of CPU time used by the process. CMD The name of the command that was entered to create the process.

ps -f With the –f option, you can now view additional information, including the following: UID The user ID of the process’ owner. PPID The PID of the process’ parent process. C The amount of processor time utilized by the process. STIME The time that the process started.

ps -l F The flags associated with the process. This column uses the following codes: 1 Forked, but didn’t execute. 4 Used root privileges. S The state of the process. This column uses the following codes: D Uninterruptible sleep. R Running. S Interruptible sleep. T Stopped or traced. Z Zombied.

PRI The priority of the process. NI The nice value of the process. We’ll talk about what this means in the next section. SZ The size of the process. WCHAN The name of the kernel function in which the process is sleeping. You will see a dash (–) in this column if the process is currently running.

Prioritizing processes Setting priorities with nice Setting priorities of running processes with renice

Setting priorities with nice Syntax: nice –n nice_level command The nice value for any Linux process can range between –20 and +19. Ex: nice –n –15 vi

Setting Priorities of Running Processes with renice Syntax: renice nice_value PID  ex: PID of the vi process is 5662 renice

Managing foreground and background processes Running processes in the background Switching processes between the background and the foreground

Running Processes in the Background When you enter any command at the shell prompt, a subshell is created and the process is run within it. As soon as the process exits, the subshell is destroyed. During the time that the process is running, the shell prompt of the parent shell disappears. You can’t do anything at the shell prompt unless you open a new terminal session. This happens because the process runs in the foreground

This is the default behavior for all commands entered at the shell prompt, whether the program is a text-based shell program or a graphical X Windows program. However, it is possible to run the program in the background. If you do this, the program you launch will run normally. However, control will be returned immediately to the shell. You can then use the shell to launch other programs or perform other shell tasks. Running a program in the background is very easy. All you have to do is append an ampersand (&) character to the command.

Switching Processes Between the Background and the Foreground fg This command will move a background process to the foreground. The syntax is fg job_ID. bg This command will move a foreground process to the background. To use this utility, you must first assign the foreground job a background job ID. This is done by pressing CTRL-Z. When you do, you’ll see the process stop and a background job ID assigned to the process. You can then enter bg job_ID to move the process to the background.

Ending a running process Using kill Using killall

Using kill Syntax: kill –signal PID

SIGHUP This is kill signal 1. This signal restarts the process. After a restart, the process will have exactly the same PID that it had before. This is a very useful option for restarting a service for which you’ve made changes in a configuration file. SIGINT This is kill signal 2. This signal sends a CRTL-C key sequence to the process. SIGKILL This is kill signal 9. This is a brute- force signal that kills the process. If the process was hung badly, this option will force it to stop.

SIGTERM This is kill signal 15. This signal tells the process to terminate immediately. This is the default signal sent by kill if you omit a signal in the command line. This signal allows the process to clean up after itself before exiting.

Using killall Syntax: killall –signal PID  The killall command is very similar to the kill command. The syntax is almost the same. The key difference is that killall uses the command name of the process to be killed instead of its PID.  EX: killall –15 vi

3. Schedule Processes Using the at daemon Using the cron daemon

Using the at Daemon at time At the at> prompt, enter the command(s) that you want at to run for you. Press enter if you want to add additional commands. When you’re done entering commands, press ctrl-D

Using the cron Daemon How cron works Using cron to manage scheduled system jobs Using cron to manage scheduled user jobs

How cron works The cron daemon is a service that runs continuously in the background on your system and checks a special file called a crontab file once every minute to see if there’s a scheduled job it should run. By default, the cron daemon is configured to run automatically every time the system boots on most Linux distributions. If not, you’ll need to start it manually using the cron init script in your system’s init directory.

Using cron to Manage Scheduled System Jobs The /etc/crontab file contains commands that are used to run scripts found in four different directories: /etc/cron.hourly Contains cron scripts that are run every hour. /etc/cron.daily Contains cron scripts that are run every day. /etc/cron.weekly Contains cron scripts that are run once a week. /etc/cron.monthly Contains cron scripts that are run once a month.

For example, suppose I wanted to run the tar command to back up the /home directory using the tar –cvf /media/usb/backup.tar /home command every day of every month, except Sundays, at 11:05 P.m. I could create a crontab file in /etc/crontab.d and add the following line: 5 23 * * 1-6 /bin/tar -cvf /media/usb/backup.tar /home This line in the crontab file specifies that the command be run at 5 minutes after 11:00 P.M. (23) every day (*) of every month (*) on Monday (1) through Saturday (6). System cron jobs run as the root user.

Using cron to Manage Scheduled User Jobs The cron daemon will read the /etc/cron.allow and /etc/cron.deny files when it starts up to determine who can and who can’t create crontab schedules. By default, only the /etc/cron.deny file is created automatically and it only contains a restriction for the guest user account. All other users are allowed to create crontab files to schedule jobs. If you create an /etc/cron.allow file, then only the users in that file will be allowed to create crontab files; all others will be denied.