Identifying and Handling File-Occupying Processes in Linux Systems

Nov 26, 2025 · Programming · 14 views · 7.8

Keywords: Linux file occupation | fuser command | lsof utility | process management | system troubleshooting

Abstract: This article provides an in-depth exploration of solutions for file occupation issues in Linux systems, focusing on the fuser and lsof utilities. It covers command syntax, parameter options, and practical application scenarios with detailed code examples. The content helps readers quickly identify processes using specific files and offers safe process termination guidelines. Additionally, it analyzes the root causes of file occupation errors and compares the advantages of different tools, serving as a comprehensive troubleshooting guide for system administrators and developers.

Background Analysis of File Occupation Errors

During Linux system administration, situations frequently arise where files cannot be deleted due to occupation by active processes. When executing the rm -rf file_name command, the system returns the error message rm: file_name not removed. Text file busy, indicating that the target file is currently being used by one or more processes. This typically occurs when files are opened in editors, programs are actively reading or writing file content, or files are loaded as shared libraries into memory.

Core Applications of the fuser Utility

The fuser command is an essential component of the psmisc package, specifically designed to identify processes using specified files or sockets. Its basic syntax structure is as follows:

fuser [options] file_name

Upon execution, the system returns a list containing Process IDs (PIDs), each corresponding to a process accessing the target file. For example, when detecting that file /var/log/syslog is occupied, you can run:

fuser /var/log/syslog

The output might display: /var/log/syslog: 1234 5678, indicating that processes with PIDs 1234 and 5678 are using the file.

Advanced Features of fuser

fuser offers extensive command-line options to enhance its functionality. Using the -v parameter provides more detailed output information, including process names and user details:

fuser -v /var/log/syslog

To forcibly terminate processes occupying a file, use the -k option, which sends a SIGKILL signal to relevant processes:

fuser -k file_name

For scenarios requiring finer control, specific signal types can be specified using the -s option. For instance, sending a SIGTERM signal allows processes to perform cleanup operations:

fuser -k -s TERM file_name

Supplementary Applications of lsof

As an alternative to fuser, the lsof (List Open Files) utility provides more comprehensive file usage information. This command can display detailed information including usernames and file descriptor types. A basic usage example is:

lsof | grep passwd

The output format typically includes process name, PID, username, file descriptor, and complete file path:

tail      12470    user    3r      REG  251,0     2037 51515911 /etc/passwd

This detailed output format is particularly useful for system administrators needing to understand specific usage contexts.

Practical Application Scenarios and Best Practices

In practical operations, it is recommended to first use fuser for quick diagnosis, as its output is more concise and direct. When more detailed information is required, use lsof for in-depth analysis. For situations requiring process termination, prioritize using fuser -k -s TERM over directly using SIGKILL, as this allows processes the opportunity to perform cleanup operations.

Tool Comparison and Selection Recommendations

fuser and lsof each have distinct advantages: fuser focuses on rapid detection of file usage and process management, while lsof provides more comprehensive system resource monitoring capabilities. The choice between tools depends on specific requirement scenarios—simple file occupation detection recommends fuser, while complex system diagnostics are better suited for lsof.

Security Considerations

When terminating processes occupying files, exercise caution. It is advisable to first confirm the importance of processes using the ps command to avoid accidentally killing critical system processes. For operations in production environments, validate command effects in testing environments first to ensure no impact on system stability.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.