Use lsof reply to delete log file or database by mistake

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 currently being uninstalled, as follows: # lsof/gtes11/

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, 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.

Recovering 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/messages

SYSLOGD 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. So we can view the corresponding information in/PROC/1283/FD/2 (each file descriptor for the process corresponding to a digitally named file under FD), as follows:

# head-n 10/PROC/1283/FD/2

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 (rooteverestbuilder.linux-ren.org) (gcc version 4.2.0) #1 SMP Wed Jul 11:18:32 EDT 2007

4 13:50:15 holmes86 kernel:bios-provided physical RAM Map:

4 13:50:15 holmes86 kernel:bios-e820:0000000000000000-000000000009f000 (usable)

4 13:50:15 holmes86 kernel:bios-e820:000000000009f000-00000000000a0000 (Reserved)

4 13:50:15 holmes86 kernel:bios-e820:0000000000100000-000000001f7d3800 (usable)

4 13:50:15 holmes86 kernel:bios-e820:000000001f7d3800-0000000020000000 (Reserved)

4 13:50:15 holmes86 kernel:bios-e820:00000000e0000000-00000000f0007000 (Reserved)

4 13:50:15 holmes86 kernel:bios-e820:00000000f0008000-00000000f000c000 (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: CAT/PROC/1283/FD/2 >/var/log/messages

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

Use lsof reply to delete log file or database by mistake