Got inotify poll request in wrong process – disabling inotify is a Perl warning from Linux::Inotify2 that shows up in Proxmox logs. It’s a fork-inheritance artifact, and most of the time it’s harmless.
Where it comes from
Proxmox uses Perl daemons that fork. pvedaemon, pveproxy, pvestatd — they all fork worker processes. When a process forks, the child inherits the parent’s inotify file descriptors. Linux::Inotify2 uses a poll loop, and after a fork the child can receive poll requests meant for the parent. The module detects that and disables inotify in the child, printing this exact message.
It’s not a kernel error. It’s not a filesystem problem. It’s the Perl module being defensive about a file descriptor it no longer owns.
Is it a real problem?
Almost never. The warning means the child process won’t use inotify for that particular watch. Proxmox doesn’t rely on inotify for anything critical in those daemons — it’s used for config file monitoring and some UI refresh logic. Losing it in a forked child doesn’t break backups, migrations, or VM management.
You’ll see it in syslog or journalctl, often alongside a daemon restart. If your VMs are running fine and the web UI works, ignore it.
When to actually worry
If the message appears constantly, every few seconds, and you also see daemon restarts or high CPU from pvedaemon, then something is repeatedly forking and failing. That’s a different issue — check /var/log/pveproxy/access.log and journalctl -u pvedaemon for the real error. The inotify line is just noise on top.
You can suppress the warning by setting PERL_INOTIFY2_DISABLE=1 in the environment before starting the daemon, but that’s overkill. The message is cosmetic.
My take
This is one of those log lines that looks scary but means nothing. Proxmox forum threads are full of people chasing it, and the answer is always the same: it’s a Perl module being careful after a fork. Don’t waste an evening on it. If you’re already in the logs, look at actual unresponsive host issues instead.
