Ubuntu Linux Toolbox 1000+ Commands for Ubuntu and Debian Power Users phần 7 pdf

Table 9-2: Standard Signals to Send to Processes

The kill command can send signals to processes by process ID or job number while the

killall command can signal processes by command name. Here are some examples:

$ kill 28665 Send SIGTERM to process with PID 28665

$ kill -9 4895 Send SIGKILL to process with PID 4895

$ kill -SIGCONT 5254 Continue a stopped process (pid 5254)

$ kill %3 Kill the process represented by job %3

$ killall spamd Kill all spamd daemons currently running

$ killall -SIGHUP sendmail Have sendmail processes reread config files

Signal Number Signal Name Description

1 SIGHUP Hang up from terminal or controlling process died

2 SIGINT Keyboard interrupt

3 SIGQUIT Keyboard quit

4 SIGILL Illegal instruction

6 SIGABRT Abort sent from abort function

8 SIGFPE Floating point exception

9 SIGKILL Kill signal

11 SIGSEGV Invalid memory reference

13 SIGPIPE Pipe broken (no process reading from pipe)

14 SIGALRM Timer signal from alarm system call

15 SIGTERM Termination signal

30,10,16 SIGUSR1 User-defined signal 1

31,12,17 SIGUSR2 User-defined signal 2

20,17,18 SIGCHLD Child terminated or stopped

19,18,25 SIGCONT Continue if process is stopped

17,19,23 SIGSTOP Stop the process

18,20.24 SIGTSTP Stop typed at terminal

21,21,26 SIGTTIN Terminal input for background process

22,22,27 SIGTTOU Terminal output for background process

182

Chapter 9: Checking and Managing Running Processes

82935c09.qxd:Toolbox 10/29/07 1:09 PM Page 182

The SIGKILL (9) signal, used generously by trigger-happy novice administrators,

should be reserved as a last resort. It does not allow the targeted process to exit cleanly

but forces it to end abruptly. This can potentially result in loss or corruption of data

handled by that process. The SIGHUP signal was originally used on Unix systems to

indicate that a terminal was being disconnected from a mainframe (such as from a

hang-up of a dial-in modem). However, daemon processes, such as sendmail and

httpd, were implemented to catch SIGHUP signals as an indication that those processes

should reread configuration files.

Running Processes Away from the Current Shell

If you want a process to continue to run, even if you disconnect from the current shell

session, there are several ways to go about doing that. You can use the nohup command

to run a process in a way that it is impervious to a hang-up signal:

$ nohup updatedb & Run updatedb with no ability to interrupt

# nohup nice -9 gcc hello.c & Run gcc uninterrupted and higher priority

Using nohup is different than running the command with an ampersand alone because

with nohup the command will keep running, even if you exit the shell that launched

the command.

The nohup command was commonly used in the days of slow processors and dial-up

connections (so you didn’t have to stay logged in to an expensive connection while

a long compile completed). Also, today using tools such as screen (described in

Chapter 14) you can keep a shell session active, even after you disconnect your net￾work connection to that shell.

Scheduling Processes to Run

Commands associated with the cron facility can be used to set a command to run at

a specific time (including now) so that it is not connected to the current shell. The at

command runs a command at the time you set:

$ at now +1 min Start command running in one minute

at> updatedb

at> <Ctrl+d> <EOT>

job 5 at Mon Aug 20 20:37:00 2007

$ at teatime Start command at 4pm today

$ at now +5 days Start a command in five days

$ at 06/25/08 Start a command at current time on June 25, 2008

Another way to run a command that’s not connected with the current shell is with the

batch command. With batch, you can set a command to start as soon as the processor is ready

(load average below .8):

$ batch Start command running immediately

at> find /mnt/isos | grep jpg$ > /tmp/mypics

at> <Ctrl+d> <EOT>

183

Chapter 9: Checking and Managing Running Processes

82935c09.qxd:Toolbox 10/29/07 1:09 PM Page 183

Note that after the at or batch commands you see a secondary at> prompt. Type the

command you want to run at that prompt and press Enter. After that, you can continue

to enter commands. When you are done, press Ctrl+d on a line by itself to queue the

commands you entered to run.

After the commands are entered, you can check the queue of at jobs that are set to run by

typing the atq command:

$ atq

11 Wed Sep 5 21:10:00 2007 a francois

10 Fri Aug 24 21:10:00 2007 a francois

8 Thu Aug 23 20:53:00 2007 a francois

Regular users can only see their own at jobs that are queued. The root user can see

everyone’s queued at jobs. If you want to delete an at job from the queue, use the atrm

command:

$ atrm 11 Delete at job number 11

The at and batch commands are for queuing up a command to run as a one-shot

deal. You can use the cron facility to set up commands to run repeatedly. These commands

are scripted into cron jobs which are scheduled in crontab files. There is one system

crontab file (/etc/crontab). Also, each user can create a personal crontab file that

can launch commands at times that the user chooses. To create a personal crontab file,

type the following.

$ crontab -e Create a personal crontab file

The crontab -e command opens your crontab file (or creates a new one) using the

vi text editor. Here are examples of several entries you could add to a crontab file:

15 8 * * Mon,Tue,Wed,Thu,Fri mail chris < /var/project/stats.txt

* * 1 1,4,7,10 * find / | grep .doc$ > /var/sales/documents.txt

The first crontab example shown sends a mail message to the user named chris by

directing the contents of /var/project/stats.txt into that message. That mail com￾mand is run Monday through Friday at 8:15 a.m. In the second example, on the first day

of January, April, July, and October, the find command runs to look for every .doc file

on the system and sends the resulting list of files to /var/sales/documents.txt.

The last part of each crontab entry is the command that is run. The first five fields rep￾resent the time and date the command is run. The fields from left to right are: minute

(0 to 59), hour (0 to 23), day of the month (0 to 31), month (0 to 12 or Jan, Feb, Mar, Apr,

May, Jun, Jul, Aug, Sep, Oct, Nov, or Dec), and day of the week (0 to 7 or Sun, Mon, Tue,

Wed, Thu, Fri, or Sat). An asterisk (*) in a field means to match any value for that field.

184

Chapter 9: Checking and Managing Running Processes

82935c09.qxd:Toolbox 10/29/07 1:09 PM Page 184