Linux-lsof Command Best Practices

Lsof Introduction

Lsof (list open files) is a tool that lists open files for the current system. In a Linux environment, everything is in the form of files, with files that not only access regular data, but also access to network connectivity and hardware. So, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) sockets, the system assigns a file descriptor to the application in the background, regardless of the nature of the file, which provides a common interface for the interaction between the application and the underlying operating system. Because the application opens a descriptor list of files that provides a lot of information about the application itself, it is helpful to see the list through the Lsof tool for system monitoring and troubleshooting.

Lsof use

Lsof output message Meaning

Enter lsof at the terminal to display the file opened by the system, because lsof needs to access core memory and various files, so it must be run as root to fully perform its functions.

COMMAND    PID      USER   FD      TYPE     DEVICE     SIZE       NODE      nameinit       1         root  cwd      dir       3,3       1024x768       2         /init       1         root  rtd      DIR       3,3       1024x768       2         /init       1         root  txt      REG       3,3       38432      1763452  /sbin/initinit       1         root  mem      REG       3,3       106114     1091620  /lib/libdl-2.6.soinit       1         Root  Mem      Reg       3,3       7560696    1091614  /lib/libc-2.6.soinit       1         root  mem      REG       3,3       79460      1091669  /lib/libselinux.so.1init       1         root  mem      REG       3,3       223280     1091668  /lib/libsepol.so.1init       1         root  mem      REG       3,3       564136     1091607  /lib/ld-2.6.soinit       1         root  10u      FIFO      0,15                  1309     /dev/initctl

Each row displays an open file, and all files opened by all processes are displayed by default if you do not specify a condition. The meaning of the lsof output column information is as follows:

COMMAND: Name of the process

PID: Process Identifier

USER: Process Owner

FD: File descriptor in which the application recognizes the file through a file descriptor. such as CWD, TXT, etc.

Type: File types, such as Dir, Reg, etc.

DEVICE: Specifies the name of the disk

Size: Sizes of files

Node: Index node (the identity of the file on disk)

Name: Open the exact name of the file

Where the file descriptor CWD value in the FD column represents the current working directory of the application, which is the directory that the application launches, unless it makes changes to the directory itself. TXT types of files are program code, such as the application binaries themselves or shared libraries, as shown in the list above in the/sbin/init program. The second value represents the application's file descriptor, which is an integer returned when the file is opened. As on the last line of file/dev/initctl, its file descriptor is 10. U indicates that the file is open and is in read/write mode instead of read-only ® or write-only (w) mode. Also, a capital W indicates that the application has a write lock on the entire file. This file descriptor is used to ensure that only one instance of the application can be opened at a time. When each application is initially opened, it has three file descriptors, from 0 to 2, representing standard input, output, and error streams, respectively. So most applications open files with FD starting from 3. The Type column is more intuitive than the FD column. Files and directories are called REG and Dir, respectively. The CHR and BLK, respectively, represent characters and block devices, or UNIX, FIFO, and IPV4, respectively, representing the UNIX domain sockets, first in and Out (FIFO) queues, and Internet Protocol (IP) sockets.

Lsof Common parameters

Lsof common usage is to find the name and number of files opened by the application. Can be used to find out where a particular application logs the log data, or to track an issue. For example, Linux restricts the number of files that a process can open. This is usually a large number, so there is no problem, and when needed, the application can request a larger value (up to a certain limit). If you suspect that the application is running out of file descriptors, you can use Lsof to count the number of open files for verification. The lsof syntax format is:

lsof [options] FileName

lsof  filename Displays all open files for all processes that open the specified file lsof-a indicates that two parameters must be met when the result lsof-c string   displays the command column that contains the specified characters lsof-u Username  Displays the files that belong to the user process open Lsof-g GID shows the process of attribution to GID lsof +d/dir/display directory is opened by the process file Lsof +d/dir/, but will search all directories under the directory, A relatively long time lsof-d FD Displays the process that specifies the file descriptor Lsof-n does not convert the IP to hostname, by default, without the-n parameter lsof-i to show the conditions of the process lsof-i[46] [protocol][@hostname | Hostaddr][:service|port]            IPv4 or IPV6 protocol-to-            TCP or UDP            hostname-Internet host name< C6/>HOSTADDR--IPV4 address service----            /etc/service in service name (can be more than one)            Port--and port number (can be more than one)

Example: See what happens with Port 22 now running

# lsof-i: 22COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE namesshd    1409 root    3u  IPv6   5678       TCP *:ssh (LISTEN)

To view files whose file type is txt opened by the root user process:

# lsof-a-u root-d txtcommand    PID USER  FD      TYPE DEVICE    SIZE    NODE nameinit       1    root txt       Reg    3,3   38432 1763452/sbin/initmingetty  1632 root txt       REG    3,3   14366 1763337/sbin/ Mingettymingetty  1633 root txt       REG    3,3   14366 1763337/sbin/mingettymingetty  1634 Root txt       reg    3,3   14366 1763337/sbin/mingettymingetty  1635 root txt       REG    3,3   14366 1763337/sbin/mingettymingetty  1636 Root txt       REG    3,3   14366 1763337/sbin/mingettymingetty  1637 Root txt       reg    3,3   14366 1763337/sbin/mingettykdm        1638 root txt       reg    3,3  132548 1428194/usr/bin/kdmx          1670 root txt       REG    3,3 1716396 1428336/usr/bin/xorgkdm        1671 Root txt< C42/>reg    3,3  132548 1428194/usr/bin/kdmstartkde  2427 root txt       REG    3,3  645408 1544195 /bin/bash ...  

Lsof use instance one to find who is using the file system

When uninstalling a file system, the operation will typically fail if there are any open files in the file system. Then through lsof you can find out which processes are using the file system that is currently being uninstalled, as follows:

# lsof  /gtes11/command  PID USER   FD   TYPE DEVICE SIZE NODE namebash    4208 root  cwd    DIR    3,1 4096    2/gtes11/vim     4230 root  cwd    DIR    3,1 4096    2/gtes11/

In this example, user root is doing some work in its/GTES11 directory. One bash is the instance running, and its current directory is/GTES11, and the other is that Vim is editing the file under/GTES11. To successfully uninstall/GTES11, you should abort these processes after notifying the user to ensure that the situation is correct. This example illustrates the importance of the current working directory of the application because it retains the file resources and prevents the file system from being unloaded. This is why most daemons (background processes) change their directories to the root directory, or service-specific directories (such as/var/spool/mqueue in the SendMail example) to prevent the daemon from preventing the uninstallation of unrelated file systems.

Ii. Recovery of deleted files

When a Linux computer is compromised, it is common for the log files to be deleted to conceal the attacker's traces. Administrative errors can also cause accidental deletion of important files, such as the active transaction log of the database is accidentally deleted when the old log is cleaned up. These files can sometimes be recovered by lsof.

When a process opens a file, it remains on disk as long as the process remains open for that file, even if it is deleted. This means that the process does not know that the file has been deleted, and it can still read and write to the file descriptor that was provided to it when the file was opened. In addition to this process, this file is not visible because its corresponding directory index node has been deleted.

In the/proc directory, it contains various files that reflect the kernel and the process tree. The/proc directory mounts an area that is mapped in memory, so these files and directories do not exist on disk, so when we read and write these files, we actually get the relevant information from memory. Most of the information related to lsof is stored in a directory named after the PID of the process, that is,/proc/1234 contains information about the process with PID 1234. There are various files in each process directory that allow the application to simply understand the process's memory space, file description list characters, symbolic links to files on disk, and other system information. The LSOF program uses this information and other information about the internal state of the kernel to produce its output. So lsof can display information such as the file descriptor of the process and the associated filename. That is, we can find information about the file by accessing the file descriptor of the process.

When a file in the system is accidentally deleted, as long as there are processes in the system that are accessing the file, we can recover the contents of the file from the/proc directory by lsof. If the/var/log/messages file is deleted due to misoperation, then the method to restore the/var/log/messages file is as follows:

First use lsof to see if there is currently a process open/var/logmessages file, as follows:

# lsof |grep/var/log/messagessyslogd   1283      root    2w      REG        3,3  5381017    1773647/var/log/ Messages (Deleted)

From the above information you can see that the PID 1283 (syslogd) Open file has a file descriptor of 2. You can also see that/var/log/messages has been flagged for deletion. Therefore, we can view the corresponding information in/PROC/1283/FD/2 (the file descriptor for each file represented by a digitally named process under FD), as follows:

# head-n 10/proc/1283/fd/2aug 4 13:50:15 holmes86 syslogd 1.4.1:restart. 4 13:50:15 holmes86 kernel:klogd 1.4.1, log Source =/proc/kmsg started. 4 13:50:15 holmes86 kernel:linux version 2.6.22.1-8 ([email protected]) (gcc version 4.2.0) #1 SMP Wed Jul 18 1 1:18:32 EDT 2007Aug 4 13:50:15 holmes86 kernel:bios-provided physical RAM Map:aug 4 13:50:15 holmes86 kernel:bios-e82 0:0000000000000000-000000000009f000 (usable) 4 13:50:15 holmes86 kernel:bios-e820:000000000009f000-00000000000 a0000 (Reserved) 4 13:50:15 holmes86 kernel:bios-e820:0000000000100000-000000001f7d3800 (usable) 4 13:50:15 H Olmes86 kernel:bios-e820:000000001f7d3800-0000000020000000 (Reserved) 4 13:50:15 holmes86 kernel:bios-e820:000 00000e0000000-00000000f0007000 (Reserved) 4 13:50:15 holmes86 kernel:bios-e820:00000000f0008000-00000000f000c00 0 (Reserved) 

As you can see from the information above, you can get the data you want to recover by looking at/PROC/1283/FD/2. If you can view the data through a file descriptor, you can use I/O redirection to copy it to a file, such as:

This method of recovering deleted files is useful for many applications, especially log files and databases.

Linux-lsof Command Best Practices