logrotate triggers RLIMIT permission warnings from icinga2 CLI

[danyalberchtoldlf]

Describe the bug

After updating Icinga 2 on RHEL 8 / Rocky Linux 8 systems, nightly logrotate runs produce warning messages from the icinga2 CLI in cron mail.

These warnings occur because logrotate executes a postrotate command invoking icinga2 internal signal ... as the icinga user.

The icinga2 binary attempts to adjust RLIMIT_NOFILE and RLIMIT_NPROC even when it lacks permission, causing “Permission denied” warnings.

Example from cron mail:

[2025-10-22 03:32:01 +0200] warning/Application: Failed to adjust resource limit for open file handles (RLIMIT_NOFILE) with error "Permission denied"
[2025-10-22 03:32:01 +0200] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Permission denied"

These warnings appear even though log rotation completes successfully and Icinga continues to operate normally.

To Reproduce

1. Run Icinga2 on RHEL 8 / Rocky Linux 8.
2. Use the default logrotate configuration (installed by package):

/var/log/icinga2/icinga2.log /var/log/icinga2/debug.log {
daily
rotate 7
su icinga icinga
compress
delaycompress
missingok
notifempty
postrotate
    /usr/sbin/icinga2 internal signal --sig SIGUSR1 --pid "$(cat /run/icinga2/icinga2.pid 2> /dev/null)" 2> /dev/null || true
endscript
}

3. Let /etc/cron.daily/logrotate run overnight (cron mails captured).
4. Observe warning lines like those above in the mail output.

Directly running the command reproduces it:

sudo -u icinga /usr/sbin/icinga2 internal signal --sig SIGUSR1 --pid "$(cat /run/icinga2/icinga2.pid)"

Expected behavior

The icinga2 internal signal command should not attempt to modify resource limits when executed by a non-root user.

It should simply send the signal and exit quietly. No “Permission denied” warnings should be emitted during normal, non-privileged invocations.

Screenshots

N/A — see warning messages above.

Your Environment

• Version used (icinga2 --version): r2.15.1-1
• Operating System and version: Rocky Linux 8.10 (Green Obsidian)
• Enabled features (icinga2 feature list): api checker mainlog
• Icinga Web 2 version and modules: N/A
• Config validation (icinga2 daemon -C): OK
• Setup: Single Icinga2 agent instance, standard package install

Additional context

Since the logrotate job runs as the icinga user (su icinga icinga), these setrlimit() calls fail with “Permission denied.”

No functional issue occurs — logs rotate and reopen correctly — but the CLI should suppress or skip resource limit adjustments when running unprivileged.

A minimal workaround is to modify /etc/logrotate.d/icinga2 as follows:

-postrotate
-    /usr/sbin/icinga2 internal signal --sig SIGUSR1 --pid "$(cat /run/icinga2/icinga2.pid 2> /dev/null)" 2> /dev/null || true
-endscript

+postrotate
+    /bin/kill -USR1 "$(cat /run/icinga2/icinga2.pid 2>/dev/null)" >/dev/null 2>&1 || true
+endscript

This uses a direct system call (kill -USR1) which reopens log files without invoking the Icinga 2 binary, avoiding RLIMIT handling and eliminating the warnings.

Ideally, icinga2 internal signal should detect non-root execution and skip resource limit changes entirely.

[yhabteab]

Hi @danyalberchtoldlf, thanks for reporting!

These warnings occur because logrotate executes a postrotate command invoking icinga2 internal signal ... as the icinga user.

How do you manage to get logrotate run the postrotate script as the icinga user? By changing its systemd unit file? Aren't any other service on your system that makes use of it or it's only being used for the Icinga 2 service?

Since the logrotate job runs as the icinga user (su icinga icinga), these setrlimit() calls fail with “Permission denied.”

The su logrotate directive is only used to rototate the log file as the specified user and group and not to execute the scripts:

su user group
Rotate log files set under this user and group instead of using default user/group (usually root).