Got inotify poll request in wrong process – disabling inotify: fix it on Proxmox

Got inotify poll request in wrong process – disabling inotify on Proxmox is just the kernel telling you a process asked for inotify events but isn’t the one getting them. It’s not a crash, but it means file watching is broken for that process. Here’s how to make it stop.

What the message actually means

inotify lets a process watch files or directories for changes. When something changes, the kernel sends an event to the process that set up the watch. The “wrong process” part means the event went to a different process than the one that requested it. That usually happens when a process forks or clones and the child inherits the inotify file descriptor but the parent still thinks it owns it. The kernel disables inotify for that descriptor to avoid delivering events to the wrong place.

On Proxmox this shows up in dmesg or the system log. It’s not specific to Proxmox — it’s a general Linux thing — but you’ll see it on a Proxmox host because there’s a lot of forking going on with QEMU, LXC, and the various daemons.

Find the process causing it

First, check the log to see which process is complaining:

dmesg | grep inotify

Or look in the journal:

journalctl -k | grep inotify

The message should include a process name or PID. If it’s a VM or container, you’ll see something like qemu-system-x86_64 or lxc-start. That tells you where to look.

The fix that actually works

The real problem is usually a process that forks and then both parent and child try to use the same inotify descriptor. The fix is to make sure only one process uses it. For QEMU, that means checking your VM configuration for anything that might cause a fork after the inotify watch is set up — like a custom hook script or a weird args line.

For LXC containers, it’s often a bind mount that gets watched by the container’s init but then the container forks a service that also watches the same path. The simplest fix is to disable inotify in the container if you don’t need it:

echo 0 > /proc/sys/fs/inotify/max_user_instances

But that’s a blunt hammer. Better to find the service inside the container that’s watching files and stop it, or make sure it doesn’t fork after setting up the watch. If it’s a systemd service, check for Type=forking — that’s a common cause. Change it to Type=simple if the service doesn’t actually need to fork.

If the message is from the Proxmox host itself, not a container, look at the pvedaemon or pveproxy processes. They fork workers, and if a worker inherits an inotify descriptor from the parent, you’ll get this. Restarting the service usually clears it:

systemctl restart pvedaemon pveproxy

But the underlying bug might still be there. Check if you have any custom patches or third-party modules loaded. The Proxmox kernel is based on Ubuntu, and sometimes a module update fixes it.

My take

Honestly, this message is annoying but rarely breaks anything. It’s a warning that file watching isn’t working for that process, so if you rely on live reload or automatic config updates, that’s when it bites. If you don’t need inotify for that process, you can ignore it. But if you do, the fork thing is the first place to look. And if it’s a container, just check the service type — that’s the usual culprit.

If you’re seeing this on a Proxmox host with LXC containers, you might also want to check proxmox backup skips bind-mounted NAS datasets in unprivileged LXC containers because bind mounts and inotify don’t always play nice together.