Introduction to Linux. Lesson 4.Unix Command Line. Part 3.
10K+
You will often need to determine where and by whom disk space is being consumed, especially when you’re running low on it! The du command allows you to determine the disk utilization on a directory-by-directory basis. Following are some of the options available. Option for du Description -c Produces a grand total at the end of the run. -h Prints sizes in human-readable format. -k Prints sizes in kilobytes rather than block sizes. (Note: Under Linux, one block is equal to 1K, but this is not true for all forms of UNIX.) -s Summarizes. Prints only a total for each argument. To display the total amount of space being used by all the files and directories in your PWD in human-readable format, use this command: [yyang@fedora-serverA ~]$ du -sh . 2.2M
The which command searches your entire path to find the name of an executable specified on the command line. If the file is found, the command output includes the actual path to the file. Use the following command to find out which directory the binary for the rm command is located in: [yyang@fedora-serverA ~]$ which rm /bin/rm You may find this similar to the find command. The difference here is that since which only searches the path, it is much faster. Of course, it is also much more limiting than find, but if all you’re looking for is a program, you’ll find it to be a better choice of commands.
The whereis tool searches your path and displays the name of the program and its absolute directory, the source file (if available), and the man page for the command (again, if available). To find the location of the program, source, and manual page for the command grep, use this: [yyang@fedora-serverA ~]$ whereis grep grep: /bin/grep /usr/share/man/man1/grep.1.gz /usr/share/man/man1p/grep.1p.gz
The df program displays the amount of free space partition by partition (or volume by volume). The drives/partitions must be mounted in order to get this information. Network File System (NFS) information can be gathered this way as well. Some parameters for df are listed here; additional (rarely used) options are listed in the df manual page. Option for df Description -h Generates free-space amount in human-readable numbers rather than free blocks. -l Lists only the locally mounted file systems. Does not display any information about network-mounted file systems. To show the free space for all locally mounted drives, use this command: [yyang@fedora-serverA ~]$ df -l To show the free space in a human-readable format for the all file systems [yyang@fedora-serverA ~]$ df -h
Like most other modern operating systems, Linux maintains a disk cache to improve efficiency. The drawback, of course, is that not everything you want written to disk will have been written to disk at any given moment. To schedule the disk cache to be written out to disk, you use the sync command. If sync detects that writing the cache out to disk has already been scheduled, the kernel is instructed to immediately flush the cache. This command takes no command-line parameters. Type this command to ensure the disk cache has been flushed: yyang@fedora-serverA ~]$ sync ; sync NOTE Manually issuing this command is rarely necessary anymore, since the Linux kernel does a good job of it on its own.
The ps command lists all the processes in a system, their state, size, name, owner, CPU time, wall clock time, and much more. Many command-line parameters are available; Option for ps Description -a Shows all processes with a controlling terminal, not just the current user’s processes -r Shows only running processes (see the description of process states later in this section) -x Shows processes that do not have a controlling terminal -u Shows the process owners -f Displays parent/child relationships among processes -l Produces a list in long format -w Shows a process’s command-line parameters (up to half a line) -ww Shows a process’s command-line parameters (unlimited width fashion) The most common set of parameters used with the ps command is auxww. These parameters show all the processes (regardless of whether they have a controlling terminal), each process’s owners, and all the processes’s command-line parameters. Let’s examine some sample output of an invocation of ps auxww. [yyang@fedora-serverA ~]$ ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.3 0.5 2136 628 ? Ss 13:05 0:09 init [2] root 2 0.0 0.0 0 0 ? S 13:05 0:00 [migration/0] root 3 0.0 0.0 0 0 ? SN 13:05 0:00 [ksoftirqd/0] root 4 0.0 0.0 0 0 ? S 13:05 0:00 [watchdog/0] root 5 0.0 0.0 0 0 ? S< 13:05 0:00 [events/0] ........OUTPUT TRUNCATED........ yyang 2384 0.0 0.7 4328 948 pts/0 R+ 13:58 0:00 ps auxww yyang 2385 0.0 0.3 4692 472 pts/0 R+ 13:58 0:00 -bash The first line of the output provides column headers for the listing, as follows: ▼ USER Who owns what process. ■ PID Process identification number. ■ %CPU Percentage of the CPU taken up by a process. Note: For a system with multiple processors, this column will add up to more than 100 percent. ■ %MEM Percentage of memory taken up by a process. ■ VSZ The amount of virtual memory a process is taking. ■ RSS The amount of actual (resident) memory a process is taking. ■ TTY The controlling terminal for a process. A question mark in this column means the process is no longer connected to a controlling terminal. ▲ STAT The state of the process. These are the possible states: ▼ S Process is sleeping. All processes that are ready to run (that is, being multitasked, and the CPU is currently focused elsewhere) will be asleep. ■ R Process is actually on the CPU. ■ D Uninterruptible sleep (usually I/O related). ■ T Process is being traced by a debugger or has been stopped. ▲ Z Process has gone zombie. This means either (1) the parent process has not acknowledged the death of its child using the wait system call; or (2) the parent was improperly killed, and until the parent is completely killed, the init process (see Chapter 8) cannot kill the child itself. A zombied process usually indicates poorly written software. In addition, the STAT entry for each process can take one of the following modifiers: W = No resident pages in memory (it has been completely swapped out); < = High-priority process; N = Low-priority task; L = Pages in memory are locked there (usually signifying the need for real-time functionality). ▼ START Date the process was started. ■ TIME Amount of time the process has spent on the CPU. ▲ COMMAND Name of the process and its command-line parameters.
This program’s name is misleading: It doesn’t really kill processes. What it does is send signals to running processes. The operating system, by default, supplies each process with a standard set of signal handlers to deal with incoming signals. From a system administrator’s standpoint, the most common handlers are for signals number 9 and 15, kill process and terminate process, respectively. When kill is invoked, it requires at least one parameter: the process identification number (PID) as derived from the ps command. When passed only the PID, kill sends signal 15. Some programs intercept this signal and perform a number of actions so that they can shut down cleanly. Others just stop running in their tracks. Either way, kill isn’t a guaranteed method for making a process stop.
An optional parameter available for kill is -n, where the n represents a signal number. As system administrators, we are most interested in the signals 9 (kill) and 1 (hang up). The kill signal, 9, is the impolite way of stopping a process. Rather than asking a process to stop, the operating system simply kills the process. The only time this will fail is when the process is in the middle of a system call (such as a request to open a file), in which case the process will die once it returns from the system call. The hang-up signal, 1, is a bit of a throwback to the VT100 terminal days of UNIX. When a user’s terminal connection dropped in the middle of a session, all of that terminal’s running processes would receive a hang-up signal (often called a SIGHUP or HUP). This gave the processes an opportunity to perform a clean shutdown or, in the case of background processes, to ignore the signal. These days, a HUP is used to tell certain server applications to go and reread their configuration files (you’ll see this in action in several of the later chapters). Most applications simply ignore the signal.
The ability to terminate a process is obviously a powerful one, making security precautions important. Users may kill only processes they have permission to kill. If nonroot users attempt to send signals to processes other than their own, error messages are returned. The root user is the exception to this limitation; root may send signals to all processes in the system. Of course, this means root needs to exercise great care when using the kill command.
NOTE. The following examples are arbitrary; the PIDs used are completely fictitious and will be different on your system. Use this command to terminate a process with PID number 205989: [root@fedora-serverA ~]# kill 205989 For an almost-guaranteed kill of process number 593999, issue this command: [root@fedora-serverA ~]# kill -9 593999 Type the following to send the HUP signal to the init program (which is always PID 1): [root@fedora-serverA ~]# kill -SIGHUP 1 This command is the same as typing [root@fedora-serverA ~]# kill - 1 1 TIP To get a listing of all the possible signals available, along with their numeric equivalents, issue the kill -l command!
We will do small lab , in order to understand kill command.
Let , start top command in backgroup:
#top &
Now , we check , which process ID for top using ps -ef command.
#ps -ef
We may see process ID for top now.
Let's kill than process :
#kill -9 ps -ef|grep top| awk '{print $2}'
Now, if we run ps -ef, it's not top at process list:
#ps -ef
The uname program produces some system details that may be helpful in several situations. Maybe you’ve managed to remotely log into a dozen different computers and have lost track of where you are! This tool is also helpful for script writers, because it allows them to change the path of a script according to the system information. Here are the command-line parameters for uname:
-m Prints the machine hardware type (such as i686 for Pentium Pro and better architectures) -n Prints the machine’s hostname -r Prints the operating system’s release name -s Prints the operating system’s release name -v Prints the operating system’s version -a Prints all of the above To get the operating system’s name and release, enter the following command: [yyang@fedora-serverA ~]$ uname -s -r NOTE The -s option may seem wasted (after all, we know this is Linux), but this parameter proves quite useful on almost all UNIX-like operating systems as well. At a Silicon Graphics, Inc. (SGI) workstation, uname -s will return IRIX, or SunOS at a Sun workstation. Folks who work in heterogeneous environments often write scripts that will behave differently, depending on the OS, and uname with -s is a consistent way to determine that information. TIP Another command that offers distribution-specific information is the the lsb_release command. Specifically, it can show Linux Standard Base (LSB)–related information, such as the distribution name, distribution code name, release or version information, etc. A common option used with the lsb_release command is -a. For example, lsb_release -a.
On systems that allow users to log into other users’ machines or special servers, you will want to know who is logged in. You can generate such a report by using the who command: [yyang@fedora-serverA ~]$ who yyang pts/0 2010-10-08 15:24 (10.35.35.51) yyang pts/1 2010-10-08 16:07 (10.35.35.51) A Variation on who: w The w command displays the same information that who does and a whole lot more. The details of the report include who is logged in, what their terminal is, where they are logged in from, how long they’ve been logged in, how long they’ve been idle, and their CPU utilization. The top of the report also gives you the same output as the uptime command. [yyang@fedora-serverA ~]$ w 16:11:24 up 1:10, 2 users, load average: 0.04, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT yyang pts/0 192.168.99.51 15:24 0.00s 0.12s 0.01s w yyang pts/1 192.168.99.51 16:07 3:35 0.04s 0.04s -bash
This command was used earlier on, when we moved a user and its home directory, and now we’ll discuss it briefly. Once you have logged into the system as one user, you need not log out and back in again in order to assume another identity (root user, for instance). Instead, use the su command to switch. This command has few command-line parameters. Running su without any parameters will automatically try to make you the root user. You’ll be prompted for the root password and, if you enter it correctly, will drop down to a root shell. If you are already the root user and want to switch to another ID, you don’t need to enter the new password when you use this command. For example, if you’re logged in as the user yyang and want to switch to the root user, type this command: [yyang@fedora-serverA ~]$ su You will be prompted for root’s password. If you’re logged in as root and want to switch to, say, user yyang, enter this command: [root@fedora-serverA ~]# su yyang You will not be prompted for yyang’s password. The optional hyphen (-) parameter tells su to switch identities and run the login scripts for that user. For example, if you’re logged in as root and want to switch over to user yyang with all of his login and shell configurations, type this command: [root@fedora-serverA ~]# su – yyang
The top command is an interactive version of ps. Instead of giving a static view of what
is going on, top refreshes the screen with a list of processes every two to three seconds
(user-adjustable). From this list, you can reprioritize processes or kill them.
The top program’s main disadvantage is that it’s a CPU hog. On a congested system,
this program tends to complicate system management issues. Users start running top
to see what’s going on, only to find several other people running the program as well,
slowing down the system even more.
By default, top is shipped so that everyone can use it. You may find it prudent,
depending on your environment, to restrict top’s use to root only. To do this, as root,
change the program’s permissions with the following command:
[root@fedora-serverA ~]# chmod 0700 which top
Content type
Image
Digest
Size
91 MB
Last updated
almost 9 years ago
docker pull marlabsdocker/lesson4