imfile inotify handling improved: safer systems, lower rsyslog impact

Large imfile deployments can put pressure on Linux inotify resources. In practice, running out of inotify watches is very uncommon, but when it does happen, the consequences used to be unpleasant and system-wide.

To address this properly, we completed a single improvement delivered in two steps: treat inotify usage as a bounded, shared system resource while keeping rsyslog itself as unaffected as possible.

One goal, two steps

The goal was clear from the beginning: handle a rare edge case correctly, without destabilizing the system or rsyslog itself.

Step one: protect the system

The first step (merged about two weeks ago) introduced the ability to limit the number of inotify watch descriptors used by imfile. That change ensures rsyslog cannot exhaust system-wide inotify resources, which could otherwise prevent other applications on the host from creating new watches.

See PR: #5523

Step two: minimize impact on rsyslog

The newly merged follow-up completes the improvement. While step one prevented system-level issues, step two ensures that rsyslog itself is impacted as little as possible when watch limits are reached. imfile now behaves more predictably under constrained conditions, reducing internal disruption and avoiding unnecessary side effects.

See PR: #6467

Operational guidance

If you ever observe your system approaching the inotify watch limit, the recommended response is simple: increase the kernel inotify limits to match the scale of the deployment.

The new safeguards ensure rsyslog behaves responsibly even in rare edge cases, but they do not replace proper system sizing. Large imfile installations may legitimately require higher limits, and modern systems are expected to be tuned accordingly.

Why this matters

Even rare failure modes deserve correct handling, especially when they involve shared kernel resources. With this two-step improvement, rsyslog now safely handles an uncommon edge case, avoids destabilizing the host system, minimizes its own operational impact, and behaves predictably under resource pressure.

This is exactly the kind of change you should never notice in day-to-day operation. And that is the point.