Jordan Ch. 9

Most Linux distributions use one of two types of init scripts: • BSD: Other Linux distributions use BSD-style init scripts. These scripts reside in the /etc/init.d directory. Within /etc/init.d are a series of directories named rc0.d through rc6.d. As with System V init scripts, these directories are associated with specific runlevels. These directories contain links that point to the init scripts in

/etc/init.d

Most Linux distributions use one of two types of init scripts: • BSD: Other Linux distributions use BSD-style init scripts. These scripts reside in the __ directory.

/etc/init.d

The actual scripts in the init directory depend on which services are installed on the particular system. Whenever a service is installed on a system with a package manager like yum, rpm, and so on, a corresponding init script is automatically installed in the init script directory. Once there, an administrator can execute any script by simply running it from the command prompt. The syntax (on a BSD-style system) is as follows:

/etc/init.d/<s.c...rpt_name> start | stop | restart.

End users can create their own scheduled jobs using a crontab file associated with their user account. Their crontab file is saved in either __, __, or __, depending on the Linux version.

/var/spool/cron/crontabs/<username>; /var/spool/cron/tabs/<username>; /var/spool/cron/<username>

An administrator cannot directly manipulate the priority of a process, but can manipulate the process's nice value. The easiest way to do this is to set the nice value when starting the command using the nice command. Any time a program starts, the default "niceness" is

0 (zero). But, the default for starting a programwith nice is 10.

Kill signals: # for SIGHUP

1

Just as cron uses the /etc/crontab file, anacron uses the /etc/anacrontab file. This file uses the following fields: (describe): The first field specifies the recurrence period (in days). For example, use any one of the following values in this field:

1 The task recurs daily. 7 The task recurs weekly. 30 The task recurs monthly.

Whereas other processes are assigned a PID randomly from the operating system's table of available PID numbers, the systemd or init process is always assigned a PID of

1.

Whereas other processes are assigned a PID randomly from the operating system's table of available PID numbers, the systemd or init process is always assigned a PID of 1. This brings up an interesting point. If the systemd or init process is the first process from which all other processes descend, what then is its PPID? Does it even have one?

Actually, it does. Because the systemd or init process is launched directly by the Linux kernel (which always has a PID of 0), the PPID of the systemd process is always 0. This is shown in Figure 9-4.

Linux Programs that can Create Processes: Type of Program with Description: (These are programs that were originally created as a text file using a programming language such as C or C++. The text file was then run through a compiler, which converts the text language into machine language. This final binary file is processed by the CPU. )

Binary executables

Use ps to display extended information about only the processes associated with the current terminal session. Which command will do this? ps ps-e ps-f ps -ef

C

Columns in top command: Column title with description: (The name of the command that was entered to start the process.)

COMMAND

Linux provides a wide variety of tools to view running processes on the system. A popular utility is the "top" program because it lists processes and updates every three seconds, ranking by

CPU utilization.

Up to now we have run, viewed, prioritized, and moved processes from background to foreground. The final topic we need to cover is how to end a process that is running on the system. Normally, enter __ to end a running process. But if the job is running in the background, __ will not work.

CTRL-C (^C)

Linux Programs that can Create Processes: Type of Program with Description: (These are text files that are interpreted through the shell itself. They include commands to run binary executables within the text of any __. )

Shell scripts

Columns in top command: S: (describe): The status of the process. Possible values include the following: S: (describe)

Sleeping

Linux administrators must become more familiar with the init replacement, systemd, and the systemctl commands. The systemd utility is superior to __ or init because it efficiently handles dependencies and performs parallel booting, thus getting systems up and running significantly faster.

SysVinit

Command "sleep 20 &". Notice that two values are displayed on the screen after the process was run in the background: (describe)

The first value, [1], is the job ID assigned to the background job, and the second value is the PID of the process.

Linux Programs that can Create Processes: Description of Type of Program: Binary executables

These are programs that were originally created as a text file using a programming language such as C or C++. The text file was then run through a compiler, which converts the text language into machine language. This final binary file is processed by the CPU.

Linux Programs that can Create Processes: Description of Type of Program: Shell scripts

These are text files that are interpreted through the shell itself. They include commands to run binary executables within the text of any shell script.

Kill signals: SIGHUP (describe)

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, such as a website, for which an end user made changes to a configuration file.

Kill signals: SIGTERM (describe)

This is kill signal 15, and the default. This signal tells the process to terminate gracefully, gently killing the child processes, and then the parent.

Kill signals: SIGINT (describe)

This is kill signal 2. This signal sends a CTRL-C key sequence to the process.

Kill signals: SIGKILL (describe)

This is kill signal 9. This is a brute-force kill and should only be used as a last resort. If the process is hung badly, this option will force it to stop, but the child processes orphan and later convert to zombies. If these are not removed, the users can wait until the next scheduled reboot. Avoid using SIGKILL on databases, mail servers, and print servers because their data could become corrupted.

Columns in top command: NI: (describe)

This is the "nice" value of the process.

Columns in top command: S: (describe): The status of the process. Possible values include the following: Value with description: (Running)

R

It's important to note that anacron also adds a random number of minutes to whatever value specified in the second field of the anacrontab file. The number of minutes that can be added is constrained by the __ variable within the /etc/anacrontab file. By default, this variable is set to a value of 45, which causes anacron to add a random number of minutes between 0 and 45 to the delay time in the anacrontab file.

RANDOM_DELAY

Columns in top command: Column title with description: (The amount of physical RAM the process is using (its resident size) in kilobytes.)

RES

Columns in top command: S: (describe): The status of the process. Possible values include the following: R: (describe)

Running

Columns in top command: Column title with description: (The status of the process. Possible values include the following: D: Uninterruptible sleep R: Running S: Sleeping T: Traced or stopped Z: Zombie)

S

Columns in top command: S: (describe): The status of the process. Possible values include the following: Value with description: (Sleeping)

S

Columns in top command: Column title with description: (The amount of shared memory used by the process.)

SHR

Kill signals: Signal with description: (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, such as a website, for which an end user made changes to a configuration file.)

SIGHUP

Kill signals: Signal with description: (This signal sends a CTRL-C key sequence to the process.)

SIGINT

Kill signals: Signal with description: (This is a brute-force kill and should only be used as a last resort. If the process is hung badly, this option will force it to stop, but the child processes orphan and later convert to zombies. If these are not removed, the users can wait until the next scheduled reboot. Avoid using __ on databases, mail servers, and print servers because their data could become corrupted.)

SIGKILL

Kill signals: Signal with description: (This signal tells the process to terminate gracefully, gently killing the child processes, and then the parent.)

SIGTERM

Kill signals: Signal with description: (the default)

SIGTERM

EXAM TIP: For users of the dd command, sending signal __ reports the dd I/O status. Simply run killall -10 dd while dd is running in the background and the user will be informed of dd's data transfer progress.

SIGUSR1

Just as cron uses the /etc/crontab file, anacron uses the /etc/anacrontab file. This file uses the following fields: The first field specifies the recurrence period (in days). For example, use any one of the following values in this field: 1 7 30 The task recurs daily. The task recurs weekly. The task recurs monthly. The second field specifies the delay (in minutes) anacron should wait before executing a skipped job after the system starts up. The third field contains the job identifier. This is the name that will be used for the job's timestamp file and must be unique for each anacron job. This file is created in the /var/spool/anacron directory and contains a single line with a timestamp that indicates the last time the particular job was run. The fourth field specifies the command or script that should be run. Consider the following example in which anacron is configured to run the /usr/bin/updatedb.sh script once a day. If the system is down when the anacron job is supposed to run, the script will execute 30 minutes after the system boots up. Notice that this file does not specify the exact time when the job will run. This is configured by the __ variable in the __ file.

START_HOURS_RANGE; /etc/anacrontab

Columns in top command: S: (describe): The status of the process. Possible values include the following: T: (describe)

Traced or stopped

Columns in top command: Column title with description: (The name of the user who owns the process.)

USER

Columns in top command: S: (describe): The status of the process. Possible values include the following: D: (Describe)

Uninterruptible sleep

EXAM TIP: There were several candidates in line to replace SysVinit or init. These included systemd and a strong contender called __. It is important to know a few systemd commands like systemctl and their options for the exam, but for __, just know it was a candidate for SysVinit replacement.

Upstart

Columns in top command: COMMAND: (describe)

The name of the command that was entered to start the process.

Columns in top command: USER: (describe)

The name of the user who owns the process.

Columns in top command: %CPU: (describe)

The percentage of CPU time used by the process.

Columns in top command: %MEM: (describe)

The percentage of available physical RAM used by the process.

Columns in top command: PR: (describe)

The priority assigned to the process. (We'll discuss process priorities later in this chapter.)

Columns in top command: PID: (describe)

The process ID of the process.

Columns in top command: S: (describe)

The status of the process. Possible values include the following: D: Uninterruptible sleep R: Running S: Sleeping T: Traced or stopped Z: Zombie

Columns in top command: TIME+: (describe)

The total amount of CPU time the process has consumed since being started.

To schedule system jobs, use crond and the /etc/crontab file to configure which jobs to run and when: In this example, the /etc/crontab file contains commands that are used to run scripts found in four different directories: /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly Contains cron scripts that are run once a month Contains cron scripts that are run every hour Contains cron scripts that are run every day Contains cron scripts that are run weekly All scripts found in any of these directories are automatically run by cron according to the specified schedule. For example, the /etc/cron.daily directory contains a variety of scripts that are used to __ and __once each day.

clean up the system; rotate the logs

Programs by default run in the foreground, whether they are a text-based shell programs or graphical programs. However, it is possible to run a program in thebackground. These programs launch normally, but

control is immediately returned to the shell. Then you can use the shell to launch other programs or perform other shell tasks.

To use the bg utility, first put the foreground job to sleep by pressing CTRL-Z(that is, press the left CTRL key and the Z key at the same time). This will cause the process to pause and then a job ID is assigned to the process. Next,

enter bg to move the process to the background, where it will continue from where it left off.

Run top by simply

entering top at the shell prompt.

Linux administrators must become more familiar with the init replacement, systemd, and the systemctl commands. The systemd utility is superior to SysVinit or init because (2)

it efficiently handles dependencies and performs parallel booting, thus getting systems up and running significantly faster.

When executed, the background process is assigned a

job ID number.

Command "sleep 20 &". Notice that two values are displayed on the screen after the process was run in the background. The first value, [1], is the job ID assigned to the background job, and the second value is the PID of the process. View all background jobs running on the system by entering __ at the shell prompt:

jobs

The __ loads the systemd or init process automatically during bootup.

kernel

One can sort top output not only by the default CPU utilization, but also by __, by __, or back to %CPU (by pressing the P key).

memory utilization (by pressing the M key); PID (by pressing the N key)

In the preceding paragraph, the term concurrently is in quotes because single- core CPUs cannot run multiple processes at the same time. Instead, Linux quickly switches between various processes running on the CPU, making it appear as if multiple processes run concurrently. However, the CPU actually only executes a single process at a time. All other processes currently "running" wait in the background for their turn. Linux maintains a schedule that determines when each process is allowed access to the CPU, called

multitasking.

The __ utility can be used on Linux to launch a program with a different priority level.

nice

Most Linux distributions use one of two types of init scripts: • BSD: Other Linux distributions use BSD-style init scripts. These scripts reside in the /etc/init.d directory. Within /etc/init.d are a series of directories named __ through __.

rc0.d; rc6.d

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 __ through __. Each of these directories is associated with a particular runlevel. Within each of these subdirectories are symbolic links that point to the init scripts for the system daemons, which reside in /etc/rc.d/init.d.

rc0.d; rc6.d

An end user creates and edits theircrontab file by running the following from the command prompt: crontab -e. After this command has been entered, the default editor is opened to create or modify the crontab file. To schedule a backup job that runs at 5:10 P.M. every day, after runningcrontab -e, enter the following: 10 17 * * * /bin/tar -cvf ~/homebak.tar ~. After editing the file, save and quit. A new or modified crontab file is completed in /var/spool/cron. In addition, the cron service is

reloaded so the new configuration can be applied.

The nice command works great for modifying the nice value when running a command to start a process. But to change the nice value of a running command, the user must use the (general command)__ command.

renice

The pgrep command lists only __ by default.

the PID of the matching processes

An administrator cannot directly manipulate the priority of a process, but can manipulate the process's nice value. The easiest way to do this is to set the nice value when starting the command using the nice command. Any time a program starts, the default "niceness" is 0 (zero). But, the default for starting a programwith nice is 10. To set higher priorities (that is, negative niceness), one must be

the administrative user or root.

The systemd or init process is responsible for launching all system processes that are configured to automatically start on bootup. It also creates a login shell that is used for login. This brings up an important point. Notice back in Figure 9-3 a second bash shell beneath the login shell. One might ask, "Couldn't I just run vi from within the login shell? Do I have to launch a second bash shell?" Actually, in this figure, vi was, in fact, launched from the login shell. Why, then, does it show a second shell between the vi process and the login shell? Because any time a user runs a command from within any shell (whether it's a login shell or a standard shell session), a second shell session is created, called asubshell, and the process for the command entered is run within it. The subshell is a separate process in and of itself and has its own PID assigned. The PPID of the subshell is the PID of the shell where the command was entered.The subshell process remains active for as long as

the command is in use. The process for the command runs within the subshell and is assigned its own PID. The PPID of the command's process is, of course, the PID of the subshell it is running within. When the command process is complete and has exited, the subshell is terminated and control is returned back to the original shell session. This process of creating a new subshell and running the command process within it is called forking.

The crond daemon is a service that runs continuously in the background and checks a special file called crontab once every minute to see if there is a scheduled job it should run. If the distribution uses init, then the cron daemon is managed using __. If the distribution uses systemd, use the __ to manage the crond daemon.

the cron init script in the init directory; systemctl command

EXAM TIP: For users of the dd command, sending signal SIGUSR1 reports

the dd I/O status. Simply run killall -10 dd while dd is running in the background and the user will be informed of dd's data transfer progress.

There are two basic ways to start a process on a Linux system. For a user process, simply enter the command or script name at the shell prompt. For example, to run the vi program, simply enter vi at the shell prompt. When done, the vi process is created, as shown here: For system processes, however, use either an init script or a service file, depending on whether

the distribution uses init or systemd. If the distribution uses the init process, an init script is used by the init process to start processes on system boot. System services would manage processes that start the web server, File Transfer Protocol (FTP) server, Secure Shell (SSH) server, Domain Name Services, and so on.

The ps command is very useful for viewing process information. However, sometimes the output of ps can be overwhelming, especially when just looking for a specific process. For example, to view just the "bash" processes running, run the following: "ps -e | grep bash". Another option for doing the same thing is to use the pgrep command. As its name implies, pgrep combines

the functionality of ps and grep into a single utility.

End users who incorrectly configure cron jobs can cause system failure; therefore, many system administrators restrict end users from using cron. This is done by utilizing the /etc/cron.allow and /etc/cron.deny files. By default, only the /etc/cron.deny file is created automatically, and it contains only one restriction by default for

the guest user account. All other users are allowed to create crontab files to schedule jobs. If the administrator creates the /etc/cron.allow file, then only the users in that file will be allowed to create crontab files; all others will be denied.

For any process on a Linux system, you need to be able to uniquely identify it as well as its heredity. 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 This is the PID of the process's parent process (that is, the process that spawned it). By assigning these two numbers to each process, you can track

the heredity of any process through the system.

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. Each of these directories is associated with a particular runlevel. Within each of these subdirectories are symbolic links that point to

the init scripts for the system daemons, which reside in /etc/rc.d/init.d.

Up to now we have run, viewed, prioritized, and moved processes from background to foreground. The final topic we need to cover is how to end a process that is running on the system. Normally, enter CTRL-C (^C) to end a running process. But if __ , ^C will not work.

the job is running in the background

Once this is configured, use the atq command to view a list of pending at jobs. Output similar the following is shown: (omitted). As a regular user, the atq command will display only

the jobs associated with the current user account. As root, atq displays all pending jobs for all users. To remove a pending job from the list, use the atrm <job_number> command.

Command "killall -15 sleep": NOTE: If the end user is running multiple sleep processes,

the killall command will terminate all of them.

The kill command is used to terminate a process using

the process ID.

The last topic to address in this objective is how to keep a process running after logging out from the system. As discussed, signals are sent to running processes to indicate that a system event has occurred and that the process needs to respond. A commonly used signal is the hang-up signal (SIGHUP). When a user logs out of a terminal session, Linux sends a SIGHUP signal to all the programs associated with that terminal. However, a process can also be told to ignore SIGHUP signals, which allows it to remain running even after the end user logs out! This is done by using the nohup utility to run the program. This causes

the process created by the command to ignore all SIGHUP signals.

As can be seen in this example, the -e option results in many more processes being displayed by the ps command. Also notice that most of the processes shown have a question mark (?) in the TTY column. This indicates

the process is a system process. Remember that system processes (daemons) are loaded by the init or systemd process at startup and are therefore not associated with any shell. Because of this, a ? is displayed in the TTY column in the output of ps.

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 This is the PID of the process's parent process (that is, the process that spawned it). By assigning these two numbers to each process, you can track the heredity of any process through the system. The Linux kernel uses the process table to keep track of the processes running on the system. The process table is maintained in memory by the operating system to facilitate switching between processes, scheduling processes, and prioritizing processes. Each entry in the table contains information about one specific running process, such as (4)

the process name, the state of the process, the priority of the process, and the memory addresses used by the process.

The nice utility can be used on Linux to launch a program with a different priority level. Recall from our previous discussion of top and ps that each process running on the system has a PR and NI value associated with it, as shown in Figure 9-9. The PR value is

the process's kernel priority. The higher the number, thelower the priority of the process. The lower the number, the higher the priority of the process. The NI value is the nice value of the process, from the adage "nice guys finish last." The nice value is factored into the kernel calculations that determine the priority of the process. The nice value for any Linux process ranges between -20 and +19. The lower the nice value, the higher the priority of the process.

An administrator cannot directly manipulate the priority of a process, but can manipulate

the process's nice value. The easiest way to do this is to set the nice value when starting the command using the nice command. Any time a program starts, the default "niceness" is 0 (zero). But, the default for starting a programwith nice is 10. To set higher priorities (that is, negative niceness), one must be the administrative user or root. The syntax is nice -n <nice_level> <command>.

Entering ps displays

the processes associated with the current shell

NOTE: System cron jobs run as

the root user!

When using kill, you can use __, or __

the signal name, such as SIGTERM; the signal value, such as 15.

View all background jobs running on the system by entering jobs at the shell prompt: In this example, the output of the jobs command displays (2)

the status of the job as well as the name of the command that was run to create the background job. To see the process ID, use the ps command.

By default, crond is configured to run automatically every time

the system boots on most Linux distributions.

Recall from our earlier discussion of processes that when entering any command at the shell prompt, a subshell is created and the process runs within it. As soon as the process exits, the subshell is destroyed. While the process is running, the "$" shell prompt is unavailable, so

the user is unable to run another command until the current process completes.

The nice utility can be used on Linux to launch a program with a different priority level. Recall from our previous discussion of top and ps that each process running on the system has a PR and NI value associated with it, as shown in Figure 9-9. The PR value is the process's kernel priority. The higher the number,

thelower the priority of the process. The lower the number, the higher the priority of the process. The NI value is the nice value of the process, from the adage "nice guys finish last." The nice value is factored into the kernel calculations that determine the priority of the process. The nice value for any Linux process ranges between -20 and +19. The lower the nice value, the higher the priority of the process.

End users who incorrectly configure cron jobs can cause system failure; therefore, many system administrators restrict end users from using cron. This is done by utilizing the /etc/cron.allow and /etc/cron.deny files. By default, only the /etc/cron.deny file is created automatically, and it contains only one restriction by default for the guest user account. All other users are allowed to create crontab files to schedule jobs. If the administrator creates the /etc/cron.allow file,

then only the users in that file will be allowed to create crontab files; all others will be denied.

Some distributions use anacron along with cron to automate the running of tasks. The two services are similar, except that cron assumes the computer system will remain up and running 24 hours a day, 7 days a week. That is fine for servers and desktops, but not for laptops or desktops that are likely to be off or asleep during certain periods of the day. If the system is not on, cron will not run. The anacron service works around this issue. If a job is scheduled in anacron, but the system is off,

then the missed job will automatically run when the system comes back up.

To learn more about kill(1) and killall(1), review their man pages. These tools are very useful, such as using the -u option with killall to

end processes owned by a specific user.

The key point to remember about user processes is that

they are called from within a shell and are associated with that shell session.

All Linux process are loaded by one single process—either called the legacy "__" or the newer "__," depending on the distribution—that is started by the Linux kernel when the system boots.

init; systemd

By default, crond is configured to run automatically every time the system boots on most Linux distributions. If not, to start it manually, do the following as root: (command)

systemctl start crond.service

To check the crond daemon status, run the following: (command)

systemctl status crond.service

There are other control characters; for example, ^C will

"cancel" a job, causing it to stop and quit

There are other control characters; for example, ^C will "cancel" a job, causing it to stop and quit, and ^D means

"done" or "end of input," to notify Linux that there is no further input.

End users can create their own scheduled jobs using a crontab file associated with their user account. Their crontab file is saved in either/var/spool/cron/crontabs/<username>, /var/spool/cron/tabs/<username>, or/var/spool/cron/<username>, depending on the Linux version. A crontab file is simply a text file that uses one line per job. Each line has six fields, separated by tabs, as detailed in Table 9-3. The crontab file also accepts characters such as the asterisk (*), comma (,) , and hyphen (-) to fine-tune the schedule for various domains and ranges. Also, the forward slash (/) can be used for

"skips." For example, */2 in the hour field means every 2 hours, instead of showing 0,2,4,6,8,10,12,14,16,18,20,22.

Recall from our earlier discussion of processes that when entering any command at the shell prompt, a subshell is created and the process runs within it. As soon as the process exits, the subshell is destroyed. While the process is running, the "$" shell prompt is unavailable, so the user is unable to run another command until the current process completes. For example, the sleep command simply

"sleeps" in the foreground for a number of seconds (doing nothing) and then prompts the user for the next command. Here's an example: "sleep 20"

Columns in top command: Column title with description: (The percentage of CPU time used by the process.)

%CPU

Columns in top command: Column title with description: ( The percentage of available physical RAM used by the process. )

%MEM

However, not all processes running on the system are user processes. In fact, most processes executing on a given Linux system will probably be of a different type, called system processes or daemons. Unlike a user process, a system process

(usually) does not provide an application or an interface for an end user to use. Instead, it is used to provide a system service, such as a web server, an FTP server, a file service such as Samba, a print service such as CUPS, or a logging service. Such processes run in the background and usually don't provide any kind of user interface.

Enter "sleep 10000" then press Ctrl-Z to see what happens in the command prompt:

*** do it ***

Using the "at" utility is a great way to schedule a process. The at service is a system daemon (called atd) that runs in the background on the system. Most Linux distributions install this service during the basic installation of the system. If not, it may need to be installed manually with a package manager like rpm, dpkg, yum, apt-get, and so on. If the distribution uses init, then the startup script used to start the atd daemon is located in the init script directory, which should be either /etc/init.d or /etc/rc.d/init.d, depending on the distribution. To check the status of at, run the following command: YouTV:~ # systemctl status atd.service To start that atd daemon, run the following as root: YouTV:~ # systemctl start atd.service To ensure that atd starts at boot time, run the following as root: YouTV:~ # systemctl enable atd.service Next, the administrator needs to specify which end users can and cannot create at jobs. This can be done by editing the following files: (2) (describe)

- /etc/at.allow Users listed in this file are allowed to create at jobs. - /etc/at.deny Users listed in this file are not allowed to create at jobs.

To schedule system jobs, use crond and the /etc/crontab file to configure which jobs to run and when: (omitted). In this example, the /etc/crontab file contains commands that are used to run scripts found in four different directories: (4) (describe)

-/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 weekly -/etc/cron.monthly Contains cron scripts that are run once a month

The nice value for any Linux process ranges between __(#) and __(#). The lower the nice value, the higher the priority of the process.

-20; +19

Entering ps displays the processes associated with the current shell. Notice that the following information is displayed by default: (4) (describe)

-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

If the Linux distribution uses systemd instead of init, then the system services are managed using service files, which have a .service extension, or what Linux terms a "suffix." Use the systemctl command at the shell prompt to start, stop, restart, or check the status of services on the system: (show commands syntaxes) (4)

-To start a service, enter "systemctl start <service_name>" -To stop a service, enter "systemctl stop <service_name>" -To restart a service, enter "systemctl restart <service_name>" -To view the status of a service, enter "systemctl status <service_name>"

Just because a process was started in the background or the foreground does not mean it has to stay there. Switch a process between foreground and background while it is running by using the following commands: (2) (general commands)

-fg This command will move a background process to the foreground. -bg This command will move a foreground process to the background.

Here, the sleep process is running with a PID of 8312: Also, any of the following could be used to kill, or specifically terminate, our sleep process: (6) (Commands)

-kill 8312 -kill -15 8312 -kill -TERM 8312 -kill -s TERM 8312 -kill -s 15 8312 -kill -s SIGTERM 8312

The pgrep command lists only the PID of the matching processes by default. To view the name of the process as well as its PID, use the __option with the pgrep command.

-l (like lion)

The ps command is very useful for viewing process information. However, sometimes the output of ps can be overwhelming, especially when just looking for a specific process. For example, to view just the "bash" processes running, run the following: Another option for doing the same thing is to use the pgrep command. As its name implies, pgrep combines the functionality of ps and grep into a single utility. When running pgrep, the end user specifies certain selection criteria to view. Then the command searches through all the currently running processes and outputs a list of processes that match the criteria specified, as shown here: Use the following options with pgrep to create the selection criteria: (2) (describe)

-l (like lion) Lists the process name and process ID -u <user_name> Matches on the specified process owner

The ps command has other options displayed within the ps(1) man page. For example, the -f option will provide "full" detail. Combined with -e, as shown here, it will result in a "full" listing of every process running on the system: The -f option displays additional information, including the following: UID The user ID of the process's owner PPID The PID of the process's parent process C The amount of processor time utilized by the process STIME The time that the process started For further detail, use the __ option with the ps command. This option displays the long format of the ps output. Here is an example combined with -e and -f: (omitted)

-l (lowercase L)

If the Linux distribution uses systemd instead of init, then the system services are managed using service files, which have a __ extension, or what Linux terms a "suffix."

.service

Just as cron uses the /etc/crontab file, anacron uses the __ file.

/etc/anacrontab

End users who incorrectly configure cron jobs can cause system failure; therefore, many system administrators restrict end users from using cron. This is done by utilizing the __ and __ files.

/etc/cron.allow and /etc/cron.deny

To schedule system jobs, use crond and the __ file to configure which jobs to run and when: (omitted)

/etc/crontab

NOTE: Because the atd service checks the /etc/at.allow file first, if an end user is listed in both /etc/at.allow and /etc/at.deny,

they will be allowed to use at!

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. Each of these directories is associated with a particular runlevel. Within each of these subdirectories are symbolic links that point to the init scripts for the system daemons, which reside in /etc/rc.d/init.d. • BSD Other Linux distributions use BSD-style init scripts. These scripts reside in the /etc/init.d directory. Within /etc/init.d are a series of directories named rc0.d through rc6.d. As with System V init scripts, these directories are associated with specific runlevels. These directories contain links that point to the init scripts in /etc/init.d. In addition to using the init process to run these scripts, administrators can run these scripts from the command prompt. Simply enter __ at the shell prompt (on a BSD-style system) or __ (on a System V-style system).

/etc/init.d/<s.c...rpt_name>; /etc/rc.d/init.d/<s.c...rpt_name>

The actual scripts in the init directory depend on which services are installed on the particular system. Whenever a service is installed on a system with a package manager like yum, rpm, and so on, a corresponding init script is automatically installed in the init script directory. Once there, an administrator can execute any script by simply running it from the command prompt. The syntax (on a BSD-style system) is as follows: /etc/init.d/<s.c...rpt_name> start | stop | restart. For example, to enable file and print services with Microsoft Windows systems, start Samba by entering __ at the shell prompt. To stop it, enter __. To restart it, enter __.

/etc/init.d/smb start; /etc/init.d/smb stop; /etc/init.d/smb restart

Using the "at" utility is a great way to schedule a process. The at service is a system daemon (called atd) that runs in the background on the system. Most Linux distributions install this service during the basic installation of the system. If not, it may need to be installed manually with a package manager like rpm, dpkg, yum, apt-get, and so on. If the distribution uses init, then the startup script used to start the atd daemon is located in the init script directory, which should be either __ or __, depending on the distribution.

/etc/init.d; /etc/rc.d/init.d

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 __ directory.

/etc/rc.d

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. Each of these directories is associated with a particular runlevel. Within each of these subdirectories are symbolic links that point to the init scripts for the system daemons, which reside in

/etc/rc.d/init.d

Just as cron uses the /etc/crontab file, anacron uses the /etc/anacrontab file. This file uses the following fields: (describe): The third field contains the job identifier. This is the name that will be used for the job's timestamp file and must be unique for each anacron job. This file is created in the __ directory and contains a single line with a timestamp that indicates the last time the particular job was run.

/var/spool/anacron

An end user creates and edits theircrontab file by running the following from the command prompt: crontab -e. After this command has been entered, the default editor is opened to create or modify the crontab file. To schedule a backup job that runs at 5:10 P.M. every day, after runningcrontab -e, enter the following: 10 17 * * * /bin/tar -cvf ~/homebak.tar ~. After editing the file, save and quit. A new or modified crontab file is completed in

/var/spool/cron

To use at to schedule jobs, complete the following steps: (4)

1. At the shell prompt enter the following: openSUSE:~ # at <time> The at daemon is very flexible as to how to specify the <time> value for the command. Observe the syntax shown in Table 9-2. 2. At the at> prompt, enter command(s) to run at the scheduled time. If the commands normally display output on the screen, an e-mail of the output is sent to the end user's account. Alternatively, one can also redirect output to a file using > or >>. Here's an example: openSUSE:~ # at now +10 minutes warning: commands will be executed using /bin/sh at> updatedb_script > $HOME/outfile 3. Press ENTER to add additional commands. To run multiple commands within the same job, each command should be on its own line. 4. When done entering commands, press CTRL-D to see <EOT>, and the at> prompt will disappear, the job will be scheduled, and a job number will be assigned, as shown here: (omitted). Once this is configured, use the atq command to view a list of pending at jobs.

When experiencing a hung process that needs to be killed, use the following sequence:(2)

1. Send a SIGTERM. Usually, this will fix the problem and allow the process to exit cleanly. If it doesn't, then go on to step 2. 2. Send a SIGKILL.

An end user creates and edits theircrontab file by running the following from the command prompt: crontab -e. After this command has been entered, the default editor is opened to create or modify the crontab file. To schedule a backup job that runs at 5:10 P.M. every day, after runningcrontab -e, enter the following:

10 17 * * * /bin/tar -cvf ~/homebak.tar ~

An administrator cannot directly manipulate the priority of a process, but can manipulate the process's nice value. The easiest way to do this is to set the nice value when starting the command using the nice command. Any time a program starts, the default "niceness" is 0 (zero). But, the default for starting a programwith nice is

10.

Kill signals: # for SIGTERM

15

End users can create their own scheduled jobs using a crontab file associated with their user account. Their crontab file is saved in either/var/spool/cron/crontabs/<username>, /var/spool/cron/tabs/<username>, or/var/spool/cron/<username>, depending on the Linux version. A crontab file is simply a text file that uses one line per job. Each line has six fields, separated by tabs, as detailed in Table 9-3: (6) (describe the fields):

1: Minutes. This field specifies the minutes past the hour that the command should run. 2. Hour. This field specifies the hour of the day when the command should be run.The cron daemon prefers military time, so use a value of 0 to 23 in this field. 3. Day. This field specifies the day of the month that the command should be run. 4. Month. This field specifies the month of the year when the command should be run. 5. Day of the week. Sunday is 0, Saturday is 6, and 1-5 means Monday through Friday. 6. The name of the command or script, using the full path, to be run.

Kill signals: # for SIGING

2

It's important to note that anacron also adds a random number of minutes to whatever value specified in the second field of the anacrontab file. The number of minutes that can be added is constrained by the RANDOM_DELAY variable within the /etc/anacrontab file. By default, this variable is set to a value of

45, which causes anacron to add a random number of minutes between 0 and 45 to the delay time in the anacrontab file.

Kill signals: # for SIGKILL

9

The myapp process (PID 2345) is currently running on the system. Which of the following commands will reset its nice value to -5 without unloading the process? (Choose two.) myapp -n -5 -p 2345 renice -n -5 2345 renice -5 2345 nice -n -5 2345

BC

Which process could be the grandparent of all processes running on a Linux system? (Choose two.) A. bashB. initC. shD. psE. systemd

BE

The systemd or init process is responsible for launching all system processes that are configured to automatically start on bootup. It also creates a login shell that is used for login. This brings up an important point. Notice back in Figure 9-3 a second bash shell beneath the login shell. One might ask, "Couldn't I just run vi from within the login shell? Do I have to launch a second bash shell?" Actually, in this figure, vi was, in fact, launched from the login shell. Why, then, does it show a second shell between the vi process and the login shell?

Because any time a user runs a command from within any shell (whether it's a login shell or a standard shell session), a second shell session is created, called asubshell, and the process for the command entered is run within it. The subshell is a separate process in and of itself and has its own PID assigned. The PPID of the subshell is the PID of the shell where the command was entered.

NOTE: Extensions, or what Linux calls suffixes (such as .service, .c, .doc, and .txt), are ignored by Linux, but are important to applications such as (4)__, and so on.

systemctl, gcc, LibreOffice, gedit

Columns in top command: S: (describe): The status of the process. Possible values include the following: Value with description: (Uninterruptible sleep)

D

Which of the following shell commands will load the myapp program with a nice value of -5? (Choose two.) myapp -n -5 nice -5 myapp renice -5 myapp nice -n -5 myapp nice --5 myapp

DE

NOTE: To change the default editor to gedit, for example, enter the following: (command)

EDITOR=/usr/bin/gedit ; export EDITOR

There are two basic ways to start a process on a Linux system: (describe)

For a user process, simply enter the command or script name at the shell prompt. For example, to run the vi program, simply enter vi at the shell prompt. When done, the vi process is created, as shown here: For system processes, however, use either an init script or a service file, depending on whether the distribution uses init or systemd. If the distribution uses the init process, an init script is used by the init process to start processes on system boot. System services would manage processes that start the web server, File Transfer Protocol (FTP) server, Secure Shell (SSH) server, Domain Name Services, and so on.

Linux Programs that can Create Processes: Type of Program with Description: ( Some of the commands entered at the shell prompt are actual binary files in the filesystem that are loaded and run by the CPU. For example, entering rm at the shell prompt will load the rm binary into memory. Other commands, however, are not binary executables. Instead, they are rolled into a shell program itself, like the "bash" shell. For example, when entering exit at a shell prompt, it actually runs an __. There is no executable file in the filesystem named "exit". )

Internal shell commands

EXAM TIP: For the Linux+ exam, make sure to know that the top utility may be used to kill processes as well using the __ key!

K

One can sort top output not only by the default CPU utilization, but also by memory utilization (by pressing the __ key), by PID (by pressing the __ key), or back to %CPU (by pressing the __ key).

M; N; P

Columns in top command: Column title with description: (This is the "nice" value of the process. )

NI

Columns in top command: Column title with description: (The process ID of the process.)

PID

Columns in top command: Column title with description: (The priority assigned to the process. (We'll discuss process priorities later in this chapter.))

PR

The nice utility can be used on Linux to launch a program with a different priority level. Recall from our previous discussion of top and ps that each process running on the system has a __ and __ value associated with it

PR; NI

Linux Programs that can Create Processes: Description of Type of Program: Internal shell commands

Some of the commands entered at the shell prompt are actual binary files in the filesystem that are loaded and run by the CPU. For example, entering rm at the shell prompt will load the rm binary into memory. Other commands, however, are not binary executables. Instead, they are rolled into a shell program itself, like the "bash" shell. For example, when entering exit at a shell prompt, it actually runs an __. There is no executable file in the filesystem named "exit".

The at Command Time Syntax Options: Type of Reference: Fixed. Description of Syntax: midnight

Specifies that a command run at 12:00 A.M.

The at Command Time Syntax Options: Type of Reference: Fixed. Description of Syntax: noon

Specifies that a command run at 12:00 P.M.

The at Command Time Syntax Options: Type of Reference: Fixed. Description of Syntax: teatime

Specifies that a command run at 4:00 P.M.

The at Command Time Syntax Options: Type of Reference: Relative. Description of Syntax: tomorrow

Specifies that the command be run tomorrow. For example: 2 pm tomorrow

The at Command Time Syntax Options: Type of Reference: Relative. Description of Syntax: now + value

Specifies that the command run at a certain time in the future. For example: now +5 minutes. now +3 days.

The at Command Time Syntax Options: Type of Reference: Relative. Description of Syntax: now

Specifies that the command run immediately.

The at Command Time Syntax Options: Type of Reference: Relative. Description of Syntax: today

Specifies that the command run today. For example: 2 pm today

The at Command Time Syntax Options: Type of Reference: Fixed. Description of Syntax: HH:MM

Specifies the exact hour and minute when the commands should run. The at daemon assumes that the hour/minute specified is today unless that time has already passed; then it assumes tomorrow. Add "am" or "pm" to the value to specify morning or afternoon, respectively.

The at Command Time Syntax Options: Type of Reference: Fixed. Description of Syntax: MMDDYY or MM/DD/YY or MM.DD.YY

Specifies the exact month, date, and year when a command is to run.

The at Command Time Syntax Options: Type of Reference: Fixed. Description of Syntax: HH:MM MMDDYY

Specifies the exact month, date, year, and time when a command is to run.

Columns in top command: S: (describe): The status of the process. Possible values include the following: Value with description: (Traced or stopped)

T

Columns in top command: Column title with description: (The total amount of CPU time the process has consumed since being started. )

TIME+

All Linux processes can trace their heredity back to the init or __ process (depending on the distribution), which is the first process loaded by the kernel on system boot.

systemd

Columns in top command: RES: (describe)

The amount of physical RAM the process is using (its resident size) in kilobytes.

Columns in top command: SHR: (describe)

The amount of shared memory used by the process.

Columns in top command: VIRT: (describe)

The amount of virtual memory used by the process.

Columns in top command: Column title with description: (The amount of virtual memory used by the process.)

VIRT

Using the "at" utility is a great way to schedule a process. The at service is a system daemon (called atd) that runs in the background on the system. Most Linux distributions install this service during the basic installation of the system. If not, it may need to be installed manually with a package manager like rpm, dpkg, yum, apt-get, and so on. If the distribution uses init, then the startup script used to start the atd daemon is located in the init script directory, which should be either /etc/init.d or /etc/rc.d/init.d, depending on the distribution. To check the status of at, run the following command:

YouTV:~ # systemctl status atd.service

Columns in top command: S: (describe): The status of the process. Possible values include the following: Value with description: (Zombie)

Z

Columns in top command: S: (describe): The status of the process. Possible values include the following: Z: (describe)

Zombie

NOTE: CTRL-Z is often shown as

^Z.

The actual scripts in the init directory depend on which services are installed on the particular system. Whenever a service is installed on a system with a package manager like yum, rpm, and so on,

a corresponding init script is automatically installed in the init script directory. Once there, an administrator can execute any script by simply running it from the command prompt.

To use the bg utility, first put the foreground job to sleep by pressing CTRL-Z(that is, press the left CTRL key and the Z key at the same time). This will cause the process to pause and then

a job ID is assigned to the process. Next, enter bgto move the process to the background, where it will continue from where it left off.

The ps command has two flavors: System V and BSD. We have demonstrated System V examples. BSD examples do not use ___. For example, to list all processes in BSD style, use the command ps aux instead of ps -elf.

a leading dash (-)

ps -e command. The figure is only showing a few lines of the output, but the -e option will display every process running on the system, not only the end-user processes. NOTE Most system processes (but not all of them) are noted with __ at the end of the name

a letter d ( which stands for daemon.)

The last topic to address in this objective is how to keep a process running after logging out from the system. As discussed, signals are sent to running processes to indicate that a system event has occurred and that the process needs to respond. A commonly used signal is the hang-up signal (SIGHUP). When a user logs out of a terminal session, Linux sends a SIGHUP signal to all the programs associated with that terminal. However,

a process can also be told to ignore SIGHUP signals, which allows it to remain running even after the end user logs out! This is done by using the nohup utility to run the program. This causes the process created by the command to ignore all SIGHUP signals.

So, what exactly is a process? For our purposes, 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.

The systemd or init process is responsible for launching all system processes that are configured to automatically start on bootup. It also creates a login shell that is used for login. This brings up an important point. Notice back in Figure 9-3 a second bash shell beneath the login shell. One might ask, "Couldn't I just run vi from within the login shell? Do I have to launch a second bash shell?" Actually, in this figure, vi was, in fact, launched from the login shell. Why, then, does it show a second shell between the vi process and the login shell? Because any time a user runs a command from within any shell (whether it's a login shell or a standard shell session), a second shell session is created, called asubshell, and the process for the command entered is run within it. The subshell is

a separate process in and of itself and has its own PID assigned. The PPID of the subshell is the PID of the shell where the command was entered.

NOTE: Most system processes (but not all of them) are noted with a letter d at the end of the name, which stands for daemon. The system has many system processes running, and these are generally loaded after the kernel is booted; therefore, they are not associated with

a shell. User processes are tied to the shell instance they were called from, but system processes are not.

Hyperthreading CPUs are designed such that

a single processor can run more than one process at a time.

End users can create their own scheduled jobs using a crontab file associated with their user account. Their crontab file is saved in either/var/spool/cron/crontabs/<username>, /var/spool/cron/tabs/<username>, or/var/spool/cron/<username>, depending on the Linux version. A crontab file is simply

a text file that uses one line per job. Each line has six fields, separated by tabs, as detailed in Table 9-3. The crontab file also accepts characters such as the asterisk (*), comma (,) , and hyphen (-) to fine-tune the schedule for various domains and ranges. Also, the forward slash (/) can be used for "skips." For example, */2 in the hour field means every 2 hours, instead of showing 0,2,4,6,8,10,12,14,16,18,20,22.

Just as cron uses the /etc/crontab file, anacron uses the /etc/anacrontab file. This file uses the following fields: The first field specifies the recurrence period (in days). For example, use any one of the following values in this field: 1 7 30 The task recurs daily. The task recurs weekly. The task recurs monthly. The second field specifies the delay (in minutes) anacron should wait before executing a skipped job after the system starts up. The third field contains the job identifier. This is the name that will be used for the job's timestamp file and must be unique for each anacron job. This file is created in the /var/spool/anacron directory and contains a single line with a timestamp that indicates the last time the particular job was run. The fourth field specifies the command or script that should be run. Consider the following example in which anacron is configured to run the /usr/bin/updatedb.sh script once a day. If the system is down when the anacron job is supposed to run, the script will execute 30 minutes after the system boots up. Notice that this file does not specify the exact time when the job will run. This is configured by the START_HOURS_RANGE variable in the/etc/anacrontab file. In the following example (START_HOURS_RANGE=3-22), the start range is set to 3-22, which specifies

a time range from 3 A.M. to 10 P.M.

To use at to schedule jobs, complete the following steps: 1. At the shell prompt enter the following: openSUSE:~ # at <time> The at daemon is very flexible as to how to specify the <time> value for the command. Observe the syntax shown in Table 9-2. 2. At the at> prompt, enter command(s) to run at the scheduled time. If the commands normally display output on the screen,

an e-mail of the output is sent to the end user's account. Alternatively, one can also redirect output to a file using > or >>. Here's an example: openSUSE:~ # at now +10 minutes warning: commands will be executed using /bin/sh at> updatedb_script > $HOME/outfile

Kill signals: SIGHUP (describe) : 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, such as a website, for which

an end user made changes to a configuration file.

There are two basic ways to start a process on a Linux system. For a user process, simply enter the command or script name at the shell prompt. For example, to run the vi program, simply enter vi at the shell prompt. When done, the vi process is created, as shown here: For system processes, however, use either

an init script or a service file, depending on whether the distribution uses init or systemd. If the distribution uses the init process, an init script is used by the init process to start processes on system boot. System services would manage processes that start the web server, File Transfer Protocol (FTP) server, Secure Shell (SSH) server, Domain Name Services, and so on.

To run a program in the background, simply

append an ampersand (&) character to the command. This tells the shell to run the program in the background.

Using the "at" utility is a great way to schedule a process. The at service is a system daemon (called __) that runs in the background on the system.

atd

To use at to schedule jobs, complete the following steps: 1. At the shell prompt enter the following: openSUSE:~ # at <time> The at daemon is very flexible as to how to specify the <time> value for the command. Observe the syntax shown in Table 9-2. 2. At the at> prompt, enter command(s) to run at the scheduled time. If the commands normally display output on the screen, an e-mail of the output is sent to the end user's account. Alternatively, one can also redirect output to a file using > or >>. Here's an example: openSUSE:~ # at now +10 minutes warning: commands will be executed using /bin/sh at> updatedb_script > $HOME/outfile 3. Press ENTER to add additional commands. To run multiple commands within the same job, each command should be on its own line. 4. When done entering commands, press CTRL-D to see <EOT>, and the at> prompt will disappear, the job will be scheduled, and a job number will be assigned, as shown here: (omitted). Once this is configured, use the __ command to view a list of pending at jobs.

atq

Once this is configured, use the atq command to view a list of pending at jobs. Output similar the following is shown: (omitted) As a regular user, the atq command will display only the jobs associated with the current user account. As root, atq displays all pending jobs for all users. To remove a pending job from the list, use the (syntax)__ command.

atrm <job_number>

For distributions that use (general command)__, use the systemctl command to start and stop system services.

systemd

To use at to schedule jobs, complete the following steps: 1. At the shell prompt enter the following: openSUSE:~ # at <time> The at daemon is very flexible as to how to specify the <time> value for the command. Observe the syntax shown in Table 9-2. 2. At the at> prompt, enter command(s) to run at the scheduled time. If the commands normally display output on the screen, an e-mail of the output is sent to the end user's account. Alternatively, one can also redirect output to a file using > or >>. Here's an example: openSUSE:~ # at now +10 minutes warning: commands will be executed using /bin/sh at> updatedb_script > $HOME/outfile 3. Press ENTER to add additional commands. To run multiple commands within the same job, each command should

be on its own line.

To schedule system jobs, use crond and the /etc/crontab file to configure which jobs to run and when: In this example, the /etc/crontab file contains commands that are used to run scripts found in four different directories: /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly Contains cron scripts that are run once a month Contains cron scripts that are run every hour Contains cron scripts that are run every day Contains cron scripts that are run weekly All scripts found in any of these directories are automatically run by cron according to the specified schedule. For example, the /etc/cron.daily directory contains a variety of scripts that are used to clean up the system and rotate the logs once each day. These scripts are shown here: If an end user has a system task that needs to be run on one of these four schedules, they can simply

create a script file and copy it into the appropriate cron directory in /etc.

End users who incorrectly configure cron jobs can cause system failure; therefore, many system administrators restrict end users from using cron. This is done by utilizing the /etc/cron.allow and /etc/cron.deny files. By default, only the /etc/cron.deny file is

created automatically, and it contains only one restriction by default for the guest user account. All other users are allowed to create crontab files to schedule jobs. If the administrator creates the /etc/cron.allow file, then only the users in that file will be allowed to create crontab files; all others will be denied.

In addition to the at daemon, use the __ daemon to schedule repeatable jobs (such as nightly backups or database updates), as discussed below.

cron

The at daemon is great, but can only schedule a job to run once in the future. Jobs often require running on a regular schedule. For example, backups may need to run daily or weekly, and Linux provides a tool for this. The cron daemon, __, can handle repetitious schedules.

crond

End users can create their own scheduled jobs using a __ file associated with their user account.

crontab

The crond daemon is a service that runs continuously in the background and checks a special file called __ once every minute to see if there is a scheduled job it should run.

crontab

End users can create their own scheduled jobs using a crontab file associated with their user account. Their crontab file is saved in either/var/spool/cron/crontabs/<username>, /var/spool/cron/tabs/<username>, or/var/spool/cron/<username>, depending on the Linux version. A crontab file is simply a text file that uses one line per job. Each line has six fields, separated by tabs, as detailed in Table 9-3. The crontab file also accepts characters such as the asterisk (*), comma (,) , and hyphen (-) to fine-tune the schedule for various domains and ranges. Also, the forward slash (/) can be used for "skips." For example, */2 in the hour field means every 2 hours, instead of showing 0,2,4,6,8,10,12,14,16,18,20,22. An end user creates and edits theircrontab file by running the following from the command prompt: (command)

crontab -e

An end user creates and edits theircrontab file by running the following from the command prompt: crontab -e. After this command has been entered, the default editor is opened to create or modify the crontab file. To schedule a backup job that runs at 5:10 P.M. every day, after runningcrontab -e, enter the following: 10 17 * * * /bin/tar -cvf ~/homebak.tar ~. After editing the file, save and quit. A new or modified crontab file is completed in /var/spool/cron. In addition, the cron service is reloaded so the new configuration can be applied. To display the crontab file updates, run the following: (command)

crontab -l

An end user creates and edits theircrontab file by running the following from the command prompt: crontab -e. After this command has been entered, the default editor is opened to create or modify the crontab file. To schedule a backup job that runs at 5:10 P.M. every day, after runningcrontab -e, enter the following: 10 17 * * * /bin/tar -cvf ~/homebak.tar ~. After editing the file, save and quit. A new or modified crontab file is completed in /var/spool/cron. In addition, the cron service is reloaded so the new configuration can be applied. To display the crontab file updates, run the following: (command) crontab -l. Finally, (command)__ removes the crontab file.

crontab -r

End users can create their own scheduled jobs using a

crontab file associated with their user account. Their crontab file is saved in either/var/spool/cron/crontabs/<username>, /var/spool/cron/tabs/<username>, or/var/spool/cron/<username>, depending on the Linux version.

Kill signals: SIGKILL (describe): This is kill signal 9. This is a brute-force kill and should only be used as a last resort. If the process is hung badly, this option will force it to stop, but the child processes orphan and later convert to zombies. If these are not removed, the users can wait until the next scheduled reboot. Avoid using SIGKILL on (3)__ because their data could become corrupted.

databases, mail servers, and print servers

Only root can __ nice values with renice.

decrease (that is, raise priority)

The ps utility can be used to display running processes on the system. Unlike top, which displays processes dynamically, ps

displays a snapshot of the current processes running.

Pressing H while top is running...

displays the help screen, which outputs the keystrokes required to sort by a particular category.

End users can create their own scheduled jobs using a crontab file associated with their user account. Their crontab file is saved in either/var/spool/cron/crontabs/<username>, /var/spool/cron/tabs/<username>, or/var/spool/cron/<username>, depending on the Linux version. A crontab file is simply a text file that uses one line per job. Each line has six fields, separated by tabs, as detailed in Table 9-3. The crontab file also accepts characters such as the asterisk (*), comma (,) , and hyphen (-) to fine-tune the schedule for various domains and ranges. Also, the forward slash (/) can be used for "skips." For example, */2 in the hour field means

every 2 hours, instead of showing 0,2,4,6,8,10,12,14,16,18,20,22.

For example, consider the processes shown in Figure 9-1 when the end user executes the ps -e command. The figure is only showing a few lines of the output, but the -e option will display

every process running on the system, not only the end-user 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 This is the PID of the process's parent process (that is, the process that spawned it). By assigning these two numbers to each process, you can track the heredity of any process through the system. The Linux kernel uses the process table to keep track of the processes running on the system. The process table is maintained (where?)

in memory by the operating system to facilitate switching between processes, scheduling processes, and prioritizing processes. Each entry in the table contains information about one specific running process, such as the process name, the state of the process, the priority of the process, and the memory addresses used by the process.

The syntax for using kill is

kill -<signal> <PID>

In addition to kill, one can also use __ to kill processes by name, which is more convenient than running ps or pgrep to determine the PID first and then running the kill command.

killall

EXAM TIP: For users of the dd command, sending signal SIGUSR1 reports the dd I/O status. Simply run (command)__ while dd is running in the background and the user will be informed of dd's data transfer progress.

killall -10 dd

The killall command syntax is similar to the kill command. For example, to kill the sleep process in the preceding example with killall instead of kill, using the TERM signal, one would run (command)

killall -15 sleep

The ps -o option allows us to

list the columns to view from ps. Sample command: "ps -o pid,pri,ni,cmd"

The kernel loads the systemd or init process automatically during bootup. The systemd or init process then launches child processes, such as a __, that in turn launch other processes, such as that used by the vi utility, as shown inFigure 9-3.

login shell

The systemd or init process is responsible for launching all system processes that are configured to automatically start on bootup. It also creates a __ that is used for login.

login shell

The ps command has two flavors: System V and BSD. We have demonstrated System V examples. BSD examples do not use a leading dash (-). For example, to list all processes in BSD style, use the command __instead of ps -elf.

ps aux

An administrator cannot directly manipulate the priority of a process, but can manipulate the process's nice value. The easiest way to do this is to set the nice value when starting the command using the nice command. Any time a program starts, the default "niceness" is 0 (zero). But, the default for starting a programwith nice is 10. To set higher priorities (that is, negative niceness), one must be the administrative user or root. The syntax is

nice -n <nice_level> <command>

The cron daemon, crond, can handle repetitious schedules. Unlike at, cron runs commands on a schedule specified by an end user. For example, many organizations setup cron jobs to run their

nightly or weekly backups.

The last topic to address in this objective is how to keep a process running after logging out from the system. As discussed, signals are sent to running processes to indicate that a system event has occurred and that the process needs to respond. A commonly used signal is the hang-up signal (SIGHUP). When a user logs out of a terminal session, Linux sends a SIGHUP signal to all the programs associated with that terminal. However, a process can also be told to ignore SIGHUP signals, which allows it to remain running even after the end user logs out! This is done by using the __ utility to run the program. This causes the process created by the command to ignore all SIGHUP signals.

nohup

The last topic to address in this objective is how to keep a process running after logging out from the system. As discussed, signals are sent to running processes to indicate that a system event has occurred and that the process needs to respond. A commonly used signal is the hang-up signal (SIGHUP). When a user logs out of a terminal session, Linux sends a SIGHUP signal to all the programs associated with that terminal. However, a process can also be told to ignore SIGHUP signals, which allows it to remain running even after the end user logs out! This is done by using the nohup utility to run the program. This causes the process created by the command to ignore all SIGHUP signals. For example, suppose a shell script called updatemydb, which automatically updates a database, runs nightly for six hours. For security reasons, the end user does not want to stay logged in to the system while updatemydb runs. To allow the script to run, and have the security of logging out, the end user can start the script with the nohup command. They just enter (command) __ at the shell prompt and then log out. If the command generates output that is usually sent to the stdout, nohup will redirect the output to the~/nohup.out file.

nohup updatemydb &

Just as cron uses the /etc/crontab file, anacron uses the /etc/anacrontab file. This file uses the following fields: (4) (describe)

period <tab> delay <tab> job-identifier <tab> command. The first field specifies the recurrence period (in days). For example, use any one of the following values in this field: 1 The task recurs daily. 7 The task recurs weekly. 30 The task recurs monthly. The second field specifies the delay (in minutes) anacron should wait before executing a skipped job after the system starts up. The third field contains the job identifier. This is the name that will be used for the job's timestamp file and must be unique for each anacron job. This file is created in the /var/spool/anacron directory and contains a single line with a timestamp that indicates the last time the particular job was run. The fourth field specifies the command or script that should be run.

Like killall, the pkill command can also stop a running process by name. The pkill command is a cousin of the __ command reviewed earlier. In fact, they use exactly the same options and even share the same man page!

pgrep

The pgrep command lists only the PID of the matching processes by default. To view the name of the process as well as its PID, use the -l option with the pgrep command. For example, to view a list of all processes owned by the cgreer user, use the following command: (sample command)

pgrep -l -u cgreer

Like killall, the (general command)__ command can also stop a running process by name.

pkill

Like killall, the pkill command can also stop a running process by name. The pkill command is a cousin of the pgrep command reviewed earlier. In fact, they use exactly the same options and even share the same man page! Again like killall, pkill will kill all processes that match the argument name. For example, to kill all running processes named "sleep" with the SIGTERM signal, execute (command)___ at the shell prompt.

pkill -SIGTERM sleep

To use the bg utility, first put the foreground job to sleep by

pressing CTRL-Z(that is, press the left CTRL key and the Z key at the same time). This will cause the process to pause and then a job ID is assigned to the process. Next, enter bgto move the process to the background, where it will continue from where it left off.

ps lists (4)

process IDs (PIDs), the terminal they are running within (TTY), how long the process has been running in CPU time (TIME), and the process command (CMD).

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 This is the PID of the process's parent process (that is, the process that spawned it). By assigning these two numbers to each process, you can track the heredity of any process through the system. The Linux kernel uses the __to keep track of the processes running on the system.

process table

The ps command has other options displayed within the ps(1) man page. For example, the -f option will

provide "full" detail. Combined with -e, as shown here, it will result in a "full" listing of every process running on the system:

Instead of having to kill a process and restart it with nice to set its nice value, use the renice command to adjust the nice value of a process that is currently running on the system. The syntax for using this command is

renice <nice_value> <PID>.

In addition to the at daemon, use the cron daemon to schedule __ jobs (such as nightly backups or database updates), as discussed below.

repeatable

End users who incorrectly configure cron jobs can cause system failure; therefore, many system administrators

restrict end users from using cron. This is done by utilizing the /etc/cron.allow and /etc/cron.deny files.

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. Each of these directories is associated with a particular

runlevel. Within each of these subdirectories are symbolic links that point to the init scripts for the system daemons, which reside in /etc/rc.d/init.d.

There are two basic ways to start a process on a Linux system. For a user process, simply enter the command or script name at the shell prompt. For example, to run the vi program, simply enter vi at the shell prompt. When done, the vi process is created, as shown here: For system processes, however, use either an init script or a service file, depending on whether the distribution uses init or systemd. If the distribution uses the init process, an init script is used by the init process to start processes on system boot. System services would manage processes that start the web server, File Transfer Protocol (FTP) server, Secure Shell (SSH) server, Domain Name Services, and so on. These scripts are stored in a specific directory on the Linux system. Which directory they are stored in depends on the Linux distribution and the __ the system is starting at. For example, __ 0 is equivalent to halt, and __ 6 is a reboot.

runlevel;

The actual scripts in the init directory depend on which services are installed on the particular system. Whenever a service is installed on a system with a package manager like yum, rpm, and so on, a corresponding init script is automatically installed in the init script directory. Once there, an administrator can execute any script by simply

running it from the command prompt.

In addition to kill, one can also use killall to kill processes by name, which is more convenient than

running ps or pgrep to determine the PID first and then running the kill command.

The at daemon is great, but can only

schedule a job to run once in the future. Jobs often require running on a regular schedule. For example, backups may need to run daily or weekly, and Linux provides a tool for this.

The ps command is very useful for viewing process information. However, sometimes the output of ps can be overwhelming, especially when just looking for a specific process. For example, to view just the "bash" processes running, run the following: "ps -e | grep bash". Another option for doing the same thing is to use the pgrep command. As its name implies, pgrep combines the functionality of ps and grep into a single utility. When running pgrep, the end user specifies certain

selection criteria to view. Then the command searches through all the currently running processes and outputs a list of processes that match the criteria specified, as shown here:

The last topic to address in this objective is how to keep a process running after logging out from the system. As discussed, signals are sent to running processes to indicate that a system event has occurred and that the process needs to respond. A commonly used signal is the hang-up signal (SIGHUP). When a user logs out of a terminal session, Linux

sends a SIGHUP signal to all the programs associated with that terminal. However, a process can also be told to ignore SIGHUP signals, which allows it to remain running even after the end user logs out! This is done by using the nohup utility to run the program. This causes the process created by the command to ignore all SIGHUP signals.

If the Linux distribution uses systemd instead of init, then the system services are managed using

service files, which have a .service extension, or what Linux terms a "suffix."

An administrator cannot directly manipulate the priority of a process, but can manipulate the process's nice value. The easiest way to do this is to

set the nice value when starting the command using the nice command. Any time a program starts, the default "niceness" is 0 (zero). But, the default for starting a programwith nice is 10. To set higher priorities (that is, negative niceness), one must be the administrative user or root. The syntax is nice -n <nice_level> <command>.

Command to run this command in the background: "sleep 20" :

sleep 20 &

There are two basic ways to start a process on a Linux system. For a user process, simply enter the command or script name at the shell prompt. For example, to run the vi program, simply enter vi at the shell prompt. When done, the vi process is created, as shown here: For system processes, however, use either an init script or a service file, depending on whether the distribution uses init or systemd. If the distribution uses the init process, an init script is used by the init process to

start processes on system boot. System services would manage processes that start the web server, File Transfer Protocol (FTP) server, Secure Shell (SSH) server, Domain Name Services, and so on.

If the Linux distribution uses systemd instead of init, then the system services are managed using service files, which have a .service extension, or what Linux terms a "suffix." Use the systemctl command at the shell prompt to (4)___ services on the system:

start, stop, restart, or check the status of

Recall from our earlier discussion of processes that when entering any command at the shell prompt, a __ is created and the process runs within it. As soon as the process exits, the __ is destroyed.

subshell

Using the "at" utility is a great way to schedule a process. The at service is a

system daemon (called atd) that runs in the background on the system. Most Linux distributions install this service during the basic installation of the system. If not, it may need to be installed manually with a package manager like rpm, dpkg, yum, apt-get, and so on.

However, not all processes running on the system are user processes. In fact, most processes executing on a given Linux system will probably be of a different type, called __ or __

system processes or daemons.

If the Linux distribution uses systemd instead of init, then the system services are managed using service files, which have a .service extension, or what Linux terms a "suffix." Use the (general command)__ command at the shell prompt to start, stop, restart, or check the status of services on the system: (omitted)

systemctl

To start that atd daemon, run the following as root: (command) systemctl start atd.service. To ensure that atd starts at boot time, run the following as root: (command)

systemctl enable atd.service

To ensure that crond starts at boot time, run the following as root: (command)

systemctl enable crond.service

To start that atd daemon, run the following as root: (command)

systemctl start atd.service

The ps command is very useful for viewing process information. However, sometimes the output of ps can be overwhelming, especially when just looking for a specific process. For example, to view just the "bash" processes running, run the following: "ps -e | grep bash". Another option for doing the same thing is to

use the pgrep command.

The Linux operating system uses several types of processes. Some processes are created by the end user when they execute a command from the shell prompt or through the graphical interface. These processes are called

user processes. User processes are usually associated with some kind of end-user program running on the system.

Kill signals: SIGKILL (describe): This is kill signal 9. This is a brute-force kill and should only be used as a last resort. If the process is hung badly, this option will force it to stop, but the child processes orphan and later convert to

zombies. If these are not removed, the users can wait until the next scheduled reboot. Avoid using SIGKILL on databases, mail servers, and print servers because their data could become corrupted.

The last topic to address in this objective is how to keep a process running after logging out from the system. As discussed, signals are sent to running processes to indicate that a system event has occurred and that the process needs to respond. A commonly used signal is the hang-up signal (SIGHUP). When a user logs out of a terminal session, Linux sends a SIGHUP signal to all the programs associated with that terminal. However, a process can also be told to ignore SIGHUP signals, which allows it to remain running even after the end user logs out! This is done by using the nohup utility to run the program. This causes the process created by the command to ignore all SIGHUP signals. For example, suppose a shell script called updatemydb, which automatically updates a database, runs nightly for six hours. For security reasons, the end user does not want to stay logged in to the system while updatemydb runs. To allow the script to run, and have the security of logging out, the end user can start the script with the nohup command. They just enter nohup updatemydb & at the shell prompt and then log out. If the command generates output that is usually sent to the stdout, nohup will redirect the output to the__ file.

~/nohup.out

For any process on a Linux system, you need to be able to uniquely identify it as well as its heredity. Whenever a process is created on a Linux system, it is assigned two resources: (describe)

• Process ID (PID) number: This is a number assigned to each process that uniquely identifies it on the system. • Parent Process ID (PPID) number: This is the PID of the process's parent process (that is, the process that spawned it).

Most Linux distributions use one of two types of init scripts: (describe)

• 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. Each of these directories is associated with a particular runlevel. Within each of these subdirectories are symbolic links that point to the init scripts for the system daemons, which reside in /etc/rc.d/init.d. • BSD: Other Linux distributions use BSD-style init scripts. These scripts reside in the /etc/init.d directory. Within /etc/init.d are a series of directories named rc0.d through rc6.d. As with System V init scripts, these directories are associated with specific runlevels. These directories contain links that point to the init scripts in /etc/init.d.