Detailed use of the lsof (listopenfiles) command

When the lsof (listopenfiles) command is used to detach a mobile storage, devicebusy is often prompted, and a file that is being opened may be deleted by mistake .... At this time, you can try lsoflsof introduction lsof (listopenfiles) is a tool to list open files in the current system... when the lsof (list open files) command is used to detach a mobile storage, device busy is often prompted. a file that is being opened may also be deleted by mistake .... At this time, you can try lsof introduction lsof (list open files) is a tool to list open files in the current system. In linux, everything exists in the form of a file. through a file, you can not only access common data, but also access network connections and hardware. Therefore, for example, the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) sockets, the system assigns a file descriptor to the application at the backend, regardless of the nature of the file, this file descriptor provides a common interface for the interaction between the application and the basic operating system. Because the descriptor list of an application opening file provides a large amount of information about the application itself, it is very helpful for system monitoring and troubleshooting to view this list using the lsof tool. Lsof uses www.2cto.com lsof to output information. enter lsof in the terminal to display the files opened by the system. because lsof needs to access the core memory and various files, therefore, you must run it as the root user to make full use of its functions.
Command pid user fd type device size node name init 1 root cwd DIR 3, 3 1024 2/init 1 root rtd DIR 3, 3 1024 2/init 1 root txt REG 3, 3 38432 1763452/sbin/init 1 root mem REG 3. 3 106114/lib/libdl-2.6.so init 1 root mem REG 3. 3 1091620 7560696/lib/libc-2.6.so init 1 root mem REG 3. 3 1091614/lib/libselinux. so.1 init 1 root mem REG 223280 1091668/lib/libsepol. so.1 init 1 root mem REG 564136 1091607/lib/ld-2.6.so init 1 root 10u FIFO 1309/dev/initctl
Each line shows an opened file. If no conditions are specified, all files opened by all processes are displayed by default.
The significance of lsof output column information is as follows:
COMMAND: Process name PID: Process identifier USER: Process owner FD: file descriptor. the application identifies the file through the file descriptor. TYPE such as cwd and txt: file TYPE, such as DIR and REG www.2cto.com DEVICE: specify disk name SIZE: file size node: index NODE (File ID on disk) NAME: the exact NAME of the opened file. the file descriptor cwd value in the FD column indicates the current working directory of the application, which is the directory started by the application unless it changes the directory. Txt files are program code, such as application binary files or shared libraries. The second value indicates the file descriptor of the application, which is an integer returned when the file is opened. The last line of the above file/dev/initctl, whose file descriptor is 10. U indicates that the file is opened and in read/write mode, rather than read-only®Or write-only (w) mode. In addition, W indicates that the application has a write lock on the entire file. This file descriptor is used to ensure that only one application instance can be opened at a time. Each initial application has three file descriptors, ranging from 0 to 2, indicating standard input, output, and error streams. Therefore, the FD of files opened by most applications starts from 3. The Type column is more intuitive than the FD column. The files and directories are called REG and DIR respectively. CHR and BLK, respectively, indicate characters and block devices; or UNIX, FIFO, and IPv4, respectively indicate UNIX domain sockets, first-in-first-out (FIFO) queues, and Internet Protocol (IP) sockets. A common lsof parameter is used to find the name and number of files opened by an application. It can be used to find out where a specific application records log data or is tracking a problem. For example, linux limits the number of files that a process can open. This value is usually very large, so there is no problem, and when necessary, the application can request a larger value (until a certain upper limit ). If you suspect that the application has exhausted the file descriptor, you can use lsof to count the number of opened files for verification. The format of lsof syntax is: lsof [options] filename
List of common parameters: lsof filename: displays all processes that open the specified file. lsof-a indicates that the two parameters must be met before the result is displayed. lsof-c string: displays all open files of processes whose names contain the specified characters in the COMMAND column. -u username: displays the files opened by the user process. lsof-g gid: displays the processes belonging to the gid. lsof + d/DIR/displays the files opened by the process in the directory. lsof + D/DIR/ same as above, however, all directories under the directory will be searched. for a relatively long time, lsof-d FD shows that the process lsof-n of the specified file descriptor does not convert the IP address to hostname, by default, the-n parameter lsof-I is not added to display the conditions of qualified processes. lsof-I [46] [protocol] [@ hostname | hostaddr] [: service | port] 46 --> IPv4 or IPv6 www.2cto.com Protocol --> TCP or UDP hostname --> Internet host name hostaddr --> IPv4 address service --> service name in/etc/service (either) port --> port number (more than one) for example: view the current running status of port 22 # lsof-I: 22 command pid user fd type device size node name sshd 1409 root 3u IPv6 5678 TCP *: ssh (LISTEN) view the files opened by the root USER process with the txt file TYPE: # lsof-a-u root-d txt command pid user fd type device size node name init 1 root txt REG 3,3 3 8432 1763452/sbin/init mingetty 1632 root txt REG 14366 1763337/sbin/mingetty 1633 root txt REG 14366 3 1763337 1634/sbin/mingetty 14366 root txt REG 1763337/sbin /mingetty 1635 root txt REG 14366 1763337/sbin/mingetty 1636 root txt REG 14366 1763337 1637/sbin/mingetty 14366 root txt REG 1763337 1638/sbin/mingetty kdm root tx T REG 132548 1428194/usr/bin/kdm X 1670 root txt REG 1716396/usr/bin/Xorg kdm 1428336 root txt REG 1671 132548/usr/bin/kdm startkde 2427 root txt REG 645408 1544195/bin/bash ...... lsof uses instance 1. Find out who is using the file system. when detaching a file system, if the file system contains any open files, the operation will usually fail. Then, you can use lsof to find out which processes are currently using the file system to be detached, as shown below: # lsof/GTES11/www.2cto.com command pid user fd type device size node name bash 4208 root cwd DIR 3, 1 4096 2/GTES11/vim 4230 root cwd DIR 3, 1 4096 2/GTES11/in this example medium, the user root is performing some operations in its/GTES11 directory. A bash instance is running, and its current directory is/GTES11, and the other shows the files that vim is editing under/GTES11. To successfully uninstall/GTES11, you should stop these processes after notifying the user to ensure normal conditions. This example shows that the current working directory of the application is very important because it still maintains file resources and can prevent the file system from being detached. This is why most Daemon (background processes) change their directories to the root directory or service-specific directories (such as/var/spool/mqueue in The sendmail example, to prevent this daemon from blocking unmounting unrelated file systems.
2. restore deleted files when Linux computers are intruded, the common situation is that log files are deleted to mask attackers. Management errors may also lead to accidental deletion of important files. for example, when clearing old logs, the active transaction logs of the database are accidentally deleted. Sometimes you can use lsof to restore these files. When a process opens a file, as long as the process keeps opening the file, even if it is deleted, it still exists in the disk. This means that the process does not know that the file has been deleted, and it can still read and write the file descriptor provided to it when the file is opened. In addition to this process, this file is invisible because the corresponding directory index node has been deleted. The/proc directory contains various files that reflect the kernel and process tree. The/proc directory is mounted to a region mapped in the memory. Therefore, these files and directories are not stored in the disk. Therefore, when we read and write these files, in fact, it is getting the relevant information from the memory. Most lsof-related information is stored in the directory named after the PID of the process, that is, the/proc/1234 contains information about the process whose PID is 1234. Each process directory contains various files, which allow applications to easily understand the memory space, file descriptor list, symbolic links to files on the disk, and other system information of the process. The lsof program uses this information and other information about the internal status of the kernel to generate its output. Therefore, lsof can display the file descriptor of a process and related file names. That is, we can find information about the file by accessing the file descriptor of the process. Www.2cto.com when a file in the system is accidentally deleted, as long as there are other processes in the system accessing the file at this time, then we can use lsof to restore the file content from the/proc directory. If the/var/log/messages file is deleted due to misoperations, the methods for restoring the/var/log/messages file are as follows: first, use lsof to check whether a process opens the/var/logmessages file, as shown below: # lsof | grep/var/log/messages syslogd 1283 root 2 w REG 5381017 1773647 1283/var/log/messages (deleted) the PID (syslogd) can be seen from the above information) the file descriptor of the opened file is 2. You can also see that/var/log/messages has been marked as deleted. Therefore, we can view the corresponding information in/proc/1283/fd/2 (each file named by number under fd represents the file descriptor corresponding to the process), as follows: # head-n 10/proc/1283/fd/2 Aug 4 13:50:15 holmes86 syslogd 1.4.1: restart. aug 4 13:50:15 holmes86 kernel: klogd 1.4.1, log source =/proc/kmsg started. aug 4 13:50:15 holmes86 kernel: Linux version 2.6.22.1-8 (root@everestbuilder.linux-ren.org) (gcc version 4.2.0) #1 SMP Wed Jul 18 11:18:32 EDT 2007 Aug 4 13:50:15 holmes86 kernel: BIOS-provided physical RAM map: Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 0000000000000000-000000000009f000 (usable) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 000000000009f000-00000000000a0000 (reserved) aug 4 13:50:15 holmes86 kernel: BIOS-e820: 0000000000100000-000000001f7d3800 (usable) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 000000001f7d3800-0000000020000000 (reserved) www.2cto.com Aug 4 13:50:15 holmes86 kernel: BIOS-e820: too many e0000000-too many f0007000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: too many f0008000-too many f000c000 (reserved) from the above information can be seen, view/proc/8663/fd/15 to obtain the data to be restored. If you can view the corresponding data through the file descriptor, you can use I/O redirection to copy it to the file, such: cat/proc/1283/fd/2>/var/log/messages is very useful for many applications, especially log files and databases. Author tianyihuyidao9