Kill: The Command to End All Commands
Linux is a powerful operating system. With its demand-paged memory management and swap file facility, it lets you start as many processes as you choose. Of course, that number is subject to overall system memory capacity (physical memory plus swap) and your CPU's ability to perform all the tasks you have requested. Starting processes is easy, and when things slow to a crawl, stopping them is just as easy.
The Linux kill command is one of two that will meet your need when you grow tired of waiting for a process to terminate. With it, you can, in the words of my 1992 Linux Programmer Manual, terminate a process with extreme prejudice. All you need to know is a number called the process PID. Note that kill doesn't always terminate another process. In essence, kill sends a signal to a specified process. If that signal is not caught and handled by the process (not all can be), the process is terminated. All of the resources that were in use by the process are released for use by other running processes.
What are processes, PIDs and signals? How are they discovered?
Recall that Linux is a multi-tasking operating system. When Linux boots, it starts a program called init, which in turn starts other programs. Many of these are background tasks like update, which periodically flushes data to the disk. Another example is getty, which watches a serial port for some sign of activity. A more visible example is the shell you use to perform useful work. It runs in the foreground, which means that it waits on your keystrokes. Each copy of each program running on your system is called a process.
Just as the US government passes out Social Security Numbers (we use Social Insurance Numbers here in Canada) to uniquely identify each individual, Linux assigns each process a unique number as an identifier. This number is called the process ID or PID.
When a process is started, it is given the next available PID, and when it terminates, its PID is released for eventual re-use. To determine the PID of any process belonging to you, enter ps at the prompt. The ps command will print, for each of your processes, a line containing the process's PID, the amount of time the process has used and the command with which the process was started. The output from ps looks like:
PID TT STAT TIME COMMAND 6651 p0 S 0:01 -ksh<\n> 6661 p1 S 0:00 -ksh 6738 p2 S 0:00 -ksh 6746 p2 S 0:00 wheel 6747 p2 S 0:00 wheel 7002 p0 S 0:01 elm 7193 p1 R 0:00 ps
Signals are a form of process communication. Because they can come from another process, the kernel or the process itself, they might be better thought of as events that occur as a program runs. A crude example might be the bell most of us remember from our early days in school; when the bell rang, we reacted by switching from playful children to industrious students.
The signals we will use below are the termination signal SIGTERM, the interrupt signal SIGINT and the kill signal SIGKILL. These signals usually occur because another process sent them. You probably already use one of them; typing ctrl-c sends the interrupt signal SIGINT to your current foreground process. Other signals—such as SIGPIPE, which is sent to a process writing to a broken pipe—usually come from the kernel. There are about 30 signals, all of which can be referred to by numbers or by names, but the numbers change between platforms and some signals are unavailable on some platforms. The complete list of signals can be found on the signal(7) manual page; enter man 7 signal to see it or enter kill -1 for a short version of this list.
For each signal there is a default action, almost all of which terminate the process. For most signals, a program may specify another action—this is called catching or handling the signal—or may specify that no action occurs, which is called ignoring the signal. The signal SIGKILL cannot be caught or ignored; it always terminates processes.
For example, suppose you use cat to list a large text file without first determining the size of the file. Instead of watching hundreds, perhaps thousands of lines scroll by too quickly to read, you send the cat process the interrupt signal by pressing Ctrl-c. Fortunately, cat was not programmed to catch SIGINT, and the cat process is terminated immediately.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide