Error 'Operation not permitted' when using kill in Linux: causes and solutions

What the error "kill: (PID) - Operation not permitted" means

This error corresponds to the EPERM (Operation not permitted) code and appears when the kill process cannot send a signal to the specified process. The full text usually looks like this:

kill: (1234) - Operation not permitted

The error means that the Linux kernel rejected the request to send a signal (e.g., SIGTERM or SIGKILL). This happens not because of a typo in the PID, but due to system restrictions: insufficient permissions, a special process state, or security policies.

Causes

1. Insufficient permissions — you are trying to terminate a process belonging to another user (e.g., root) without using sudo.
2. Process in uninterruptible sleep (D-state) — the process is waiting for a system I/O operation (often device I/O) to complete and ignores all signals, including SIGKILL.
3. Zombie process — the process has already terminated, but its entry in the process table has not been removed because the parent process has not read its status. Zombies cannot be killed.
4. Security policies — SELinux, AppArmor, or Linux capabilities may prohibit the termination of certain processes (e.g., system services).
5. Critical system processes — attempting to kill init (PID 1) or other kernel-managed processes will be rejected.

Solutions

Method 1: Check permissions and use sudo

The most common cause is lack of permissions. Ensure the process does not belong to another user:

ps -o user= -p <PID>

If the user is not you, terminate the process with sudo:

sudo kill <PID>
# Or forcefully
sudo kill -9 <PID>

⚠️ Important: The SIGKILL (-9) signal should only be used if SIGTERM (the standard kill) did not work, as it does not give the process a chance to shut down cleanly.

Method 2: Determine the process state

Check if the process is in uninterruptible sleep (D-state):

ps -o stat= -p <PID>

If the output contains the letter D (e.g., D+), the process is in uninterruptible sleep. Such processes are usually waiting for a response from a device driver (disk, NFS, network interface). They do not respond to SIGKILL.

What to do for D-state processes:

1. Find out which resource is blocking the process using strace (may require sudo):

   sudo strace -p <PID> 2>&1 | grep -i "EAGAIN\|ETIMEDOUT\|NFS"
   

2. If the process is hung due to NFS, try forcibly unmounting the filesystem:

   sudo umount -l /mount/point
   

3. If the process is disk-related (e.g., ksoftirqd), the issue may be with the driver or hardware. As a last resort — reboot the system.

Method 3: Clean up zombie processes

Zombie processes appear in ps with state Z:

ps aux | grep '^.* Z .*'

Zombies do not consume CPU or memory but occupy a process table entry. They cannot be killed — you need to terminate the parent process (PPID):

1. Find the PPID of the zombie:

   ps -o ppid= -p <ZombiePID>
   

2. Terminate the parent process (be careful, this may affect other child processes):

   sudo kill -9 <PPID>
   

   Or restart the service if it is a system process:

   sudo systemctl restart <service-name>
   

Method 4: Check SELinux and AppArmor

Security policies can block the termination of processes, especially if they belong to protected domains (e.g., httpd_t for Apache).

For SELinux:

1. Temporarily switch to permissive mode (logs but does not block):

   sudo setenforce 0
   

2. Try terminating the process again. If it worked, configure the policy:

   sudo audit2allow -M mypol < /var/log/audit/audit.log
   sudo semodule -i mypol.pp
   

3. Return to enforcing mode:

   sudo setenforce 1
   

For AppArmor:

1. Check if there is a profile for the process:

   sudo apparmor_status | grep <process_name>
   

2. Temporarily disable the profile:

   sudo apparmor_parser -R /etc/apparmor.d/usr.bin.<process>
   

3. If the problem disappears, edit the profile to add permission for signals.

Method 5: Use /proc for forced termination (last resort)

If the process ignores all signals (rare, but possible due to kernel bugs), you can try to "kill" it via the /proc filesystem:

echo 1 > /proc/<PID>/coredump_filter 2>/dev/null
echo 9 > /proc/<PID>/signal 2>/dev/null

⚠️ Experimental method. May lead to system instability. Use only if other methods failed and a reboot is not possible.

Prevention

• Terminate processes correctly — use SIGTERM (standard kill) first, then SIGKILL. This gives the process a chance to save data.
• Monitor D-states — regularly check for processes in state D via top (press D to sort) or ps aux | grep '^.* D .*'. Frequent D-state processes may indicate hardware or driver issues.
• Configure parent processes — for systemd services, ensure PIDFile is correct and KillMode is set to control-group (default). For custom scripts — always handle SIGCHLD and call wait().
• Update kernel and drivers — many uninterruptible sleep issues are fixed in updates.
• Be cautious with NFS — when mounting remote filesystems, use soft and timeo options so processes do not hang forever if the connection is lost.