Find process using file linux

How to determine which process is creating a file? [duplicate]

I thought one of the inotify_tools (inotifywatch or inotifywait) would do this kind of thing. These tools are great if you want to know when a filesystem event happens, but it doesn’t look like you can get a pid from inotify.

You could do inotifywait $file ; lsof -r1 $file , though. It’s much better than running while loops or using watch .

5 Answers 5

The lsof command (already mentioned in several answers) will tell you what process has a file open at the time you run it. lsof is available for just about every unix variant.

lsof won’t tell you about file that were opened two microseconds ago and closed one microsecond ago. If you need to watch a particular file and react when it is accessed, you need different tools.

If you can plan a little in advance, you can put the file on a LoggedFS filesystem. LoggedFS is a FUSE stacked filesystem that logs all accesses to files in a hierarchy. The logging parameters are highly configurable. FUSE is available on all major unices. You’ll want to log accesses to the directory where the file is created. Start with the provided sample configuration file and tweak it according to this guide.

loggedfs -l /path/to/log_file -c /path/to/config.xml /path/to/directory tail -f /path/to/log_file 

Many unices offer other monitoring facilities. Under Linux, you can use the relatively new audit subsystem. There isn’t much literature about it (but more than about loggedfs); you can start with this tutorial or a few examples or just with the auditctl man page. Here, it should be enough to make sure the daemon is started, then run auditctl :

(I think older systems need auditctl -a exit,always -w /path/to/file ) and watch the logs in /var/log/audit/audit.log .

Источник

Find the Process That Is Using a File in Linux

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

1. Introduction

Sometimes when we try to access a file, we may experience the message the file is busy. This means that the system is running a process that is using the file, keeping it open either for reading or writing. When this happens, sometimes we’ll want to discover the process that uses the file.

In this tutorial, we’ll look at how to find the process that is using a file.

2. Methods and Commands to Find the Process

There are a couple of commands which can help us to find processes that operate on files, so we’ll start there. These commands gather data from the Linux kernel because it is responsible for running the processes, file systems, among other things. Additionally, we’ll read the kernel tables directly to get the needed info.

2.1. The fuser Command

Let’s start with the fuser command that lists processes using files or sockets. It can also be used to kill a process. We can use it with the -v parameter to get a verbose output:

$ fuser -v text.txt USER PID ACCESS COMMAND /home/john/text.txt: john 22829 f. less 

As we can see, in this case, the less process is accessing the file. The fuser command returns the PID, the user who called the process, and the file states.

Running the command with the -k option will kill the process that it finds. Let’s give it a try to kill the less process, with SIGKILL, using the PID 24815:

$ fuser -k text.txt /home/john/text.txt: 24815 

Let’s say the same file is being accessed by vi. When we run the same command, nothing will be returned because vi opens the file, reads its content to memory, and closes it. The kernel did its job already, so information on the file is not available.

However, we can try finding the process by analyzing and guessing the output of fuser -cv text.txt. The response is a list of all processes that are accessing files on the same file system. In this case, the last line of the output is the process we’re looking for. However, that may not always be the case.

$ fuser -cv text.txt USER PID ACCESS COMMAND /home/john/text.txt: root kernel mount /home . john 24807 F.c.. vi

Running the command with the -k option may kill all processes that use the pointed file or directory, so use it with care.

2.2. The lsof Command

The lsof command can return a list of open files. To narrow down the results and keep the heading line, we’ll use it with the head and grep commands. Assuming vi is still running, let’s give it a try:

$ lsof | < head -1 ; grep text.txt ; >COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME vi 24807 john 4u REG 8,3 12288 3147621 /home/john/.text.txt.swp

The lsof command returns the process name, the PID, and the user who is running the process. If the process has threads, we’ll see their identification number, TID, with the task command. The FD field can have three parts: file descriptor (4 in our case) is the first, a mode character is the second (u means the file is accessible for reading and writing), and a lock character is the third.

Let’s look at the output when the less command is accessing the file, instead of vi:

$ lsof | < head -1 ; grep text.txt ; >COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME less 28423 john 4r REG 8,3 75 3146117 /home/john/text.txt

In this case, we see that the file is opened for reading, with FD = 4r.

Just as with fuser, however, if we’re using vi to edit the file, lsof won’t show it as in use.

The command has plenty of options. For instance, the -t gives only process identifiers without a header, making it helpful in writing scripts.

lsof is very similar to fuser, except it can’t kill the processes. However, because lsof also gives us the PID, we can join it with the kill command:

To discover PIDs of all processes using files in a directory and below, we can recursively scan it with +D.

Additionally, lsof is frequently used to find all files opened by a given (by PID) process:

2.3. Getting Information From the Kernel Directly

Another way of detecting the process of a file in use is by accessing the kernel directly. The kernel keeps the data under /proc. Information about a process is in the directory /proc/ . It contains entries for everything opened by the process file, named by its file descriptor, which is linked to the actual file.

#!/usr/bin/bash for pid in /proc/*; do i=$(basename "$pid") for file in "$pid"/fd/*; do link=$(readlink -e "$file") if [ "$link" ]; then echo "PID $i: $link" fi done done | grep $1 

$ ./mylsof text.txt PID 30069: /home/john/text.txt

$ lsof /dev/null 

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1480 tecmint 0r CHR 1,3 0t0 6 /dev/null sh 1501 tecmint 0r CHR 1,3 0t0 6 /dev/null sh 1501 tecmint 1w CHR 1,3 0t0 6 /dev/null dbus-daem 1530 tecmint 0u CHR 1,3 0t0 6 /dev/null xfce4-ses 1603 tecmint 0r CHR 1,3 0t0 6 /dev/null xfce4-ses 1603 tecmint 1w CHR 1,3 0t0 6 /dev/null at-spi-bu 1604 tecmint 0r CHR 1,3 0t0 6 /dev/null dbus-daem 1609 tecmint 0u CHR 1,3 0t0 6 /dev/null at-spi2-r 1611 tecmint 0u CHR 1,3 0t0 6 /dev/null xfconfd 1615 tecmint 0u CHR 1,3 0t0 6 /dev/null xfwm4 1624 tecmint 0r CHR 1,3 0t0 6 /dev/null xfwm4 1624 tecmint 1w CHR 1,3 0t0 6 /dev/null xfce4-pan 1628 tecmint 0r CHR 1,3 0t0 6 /dev/null xfce4-pan 1628 tecmint 1w CHR 1,3 0t0 6 /dev/null Thunar 1630 tecmint 0r CHR 1,3 0t0 6 /dev/null Thunar 1630 tecmint 1w CHR 1,3 0t0 6 /dev/null xfdesktop 1632 tecmint 0r CHR 1,3 0t0 6 /dev/null xfdesktop 1632 tecmint 1w CHR 1,3 0t0 6 /dev/null .

$ lsof -u tecmint 

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1480 tecmint cwd DIR 8,3 4096 2 / systemd 1480 tecmint rtd DIR 8,3 4096 2 / systemd 1480 tecmint txt REG 8,3 1595792 3147496 /lib/systemd/systemd systemd 1480 tecmint mem REG 8,3 1700792 3150525 /lib/x86_64-linux-gnu/libm-2.27.so systemd 1480 tecmint mem REG 8,3 121016 3146329 /lib/x86_64-linux-gnu/libudev.so.1.6.9 systemd 1480 tecmint mem REG 8,3 84032 3150503 /lib/x86_64-linux-gnu/libgpg-error.so.0.22.0 systemd 1480 tecmint mem REG 8,3 43304 3150514 /lib/x86_64-linux-gnu/libjson-c.so.3.0.1 systemd 1480 tecmint mem REG 8,3 34872 2497970 /usr/lib/x86_64-linux-gnu/libargon2.so.0 systemd 1480 tecmint mem REG 8,3 432640 3150484 /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 systemd 1480 tecmint mem REG 8,3 18680 3150450 /lib/x86_64-linux-gnu/libattr.so.1.1.0 systemd 1480 tecmint mem REG 8,3 18712 3150465 /lib/x86_64-linux-gnu/libcap-ng.so.0.0.0 systemd 1480 tecmint mem REG 8,3 27112 3150489 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 systemd 1480 tecmint mem REG 8,3 14560 3150485 /lib/x86_64-linux-gnu/libdl-2.27.so .

$ sudo lsof -i TCP:80 

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME httpd 903 root 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 1320 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 1481 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 1482 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 1493 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 1763 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 2027 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 2029 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 2044 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 3199 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN) httpd 3201 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)