openSUSE systemd‑journald rate limiting suppresses repeated log events that trigger desktop alerts

For most openSUSE desktop installations, a RateLimitBurst value between 2500 and 5000 typically provides a sufficient trade-off. This range is generally high enough to accommodate the erratic logging bursts common in desktop environments—such as those triggered by peripheral events or GUI state changes—while remaining low enough to prevent a runaway process from exhausting disk space or masking other critical system errors.

Impact on YaST2-alert-mail Timeliness

The systemd-journald rate limiting mechanism suppresses log lines once the RateLimitBurst threshold is reached within the RateLimitInterval (which defaults to 30 seconds in many configurations). Because YaST2-alert-mail and similar monitoring tools trigger based on the presence of these log entries, any suppressed line results in a missed or delayed notification.

Increasing the burst limit ensures that state-change notifications are recorded and processed immediately within the active 30-second window, rather than being discarded during a period of high logging volume.

Implementation Steps

To adjust these limits without modifying the main configuration file (preserving them across system updates), use a drop-in file:

1. Create the configuration directory: sudo mkdir -p /etc/systemd/journald.conf.d/
2. Create a file (e.g., /etc/systemd/journald.conf.d/alerts.conf) with the following content:

   [Journal]
   RateLimitIntervalSec=30s
   RateLimitBurst=3000

3. Restart the service to apply changes: sudo systemctl restart systemd-journald

Verification

Confirm the active settings are recognized by the system:

grep -i RateLimit /etc/systemd/journald.conf /etc/systemd/journald.conf.d/*.conf

To verify that the new limit prevents suppression, you can generate a controlled burst and check the count:

for i in {1..1500}; do logger -t test-burst "Message $i"; done
journalctl -t test-burst --since "1 minute ago" | wc -l

Desktop vs. Server Profile Defaults

It is advisable to maintain separate defaults for desktop and server profiles. Desktop environments exhibit higher variance in log volume due to user-driven interactions. Server environments, however, prioritize predictability; a lower burst limit is safer on servers to ensure that a single malfunctioning daemon cannot flood the logs and obscure other critical system failures.

Diagnostic Note: To determine if these higher limits are appropriate for your specific hardware, please provide your current SystemMaxUse setting. If your journal is restricted to a very small disk quota, a more conservative burst value may be required to prevent premature log rotation.