iRedMail — systemd[1]: Looping too fast. Throttling execution a little.

Re: systemd[1]: Looping too fast. Throttling execution a little.

null@example.com (dittman) — Wed, 03 Dec 2025 02:17:24 +0000

Another burst starting at 3:00 AM local time and I still can't find any job scheduled for that time.

But it seems that it's not actually impacting the system operation so I think I'm good to do the cutover.

But again, if anyone else is running Rocky 10.1 and can check to see if they see the same thing it would be helpful.

Re: systemd[1]: Looping too fast. Throttling execution a little.

null@example.com (dittman) — Mon, 01 Dec 2025 21:45:22 +0000

Cthulhu wrote:

could be freshclam maybe

Looking at journalctl -u clamav-freshclam I don't see any errors and the wakeup was at 03:20 so before the looping messages.

I did a journalctl without any filtering and it looks like it might be "/bin/bash /usr/local/bin/fail2ban_banned_db unban_db". That seems to be run shortly before the bursts, but I don't see any actual error messages so I'll look further into that.

Re: systemd[1]: Looping too fast. Throttling execution a little.

null@example.com (Cthulhu) — Mon, 01 Dec 2025 21:09:15 +0000

could be freshclam maybe

Re: systemd[1]: Looping too fast. Throttling execution a little.

null@example.com (dittman) — Mon, 01 Dec 2025 18:29:24 +0000

Okay, after several hours with the rsync job disabled the Looping errors came back, it started at 3:00 AM local time and went on for 15 minutes, so I need to dig into it some more.

Re: systemd[1]: Looping too fast. Throttling execution a little.

null@example.com (dittman) — Sun, 30 Nov 2025 23:14:41 +0000

Since the only difference was the rsync job I disabled it and the errors went away. I'm not sure why it's generating the errors, but that's the issue.

The rsync job just runs once every 30 minutes and there's not a ton of emails to sync so it shouldn't be causing this.

systemd[1]: Looping too fast. Throttling execution a little.

null@example.com (dittman) — Sun, 30 Nov 2025 17:38:20 +0000

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.7.4 MARIADB edition.
- Deployed with iRedMail Easy or the downloadable installer? downloadable installer
- Linux/BSD distribution name and version: Rocky Linux release 10.1 (Red Quartz)
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MariaDB
- Web server (Apache or Nginx): NGINX
- Manage mail accounts with iRedAdmin-Pro? No
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

I've prepared a new server with Rocky Linux 10.1 (upgraded from a fresh install of 10). I've got iRedMail 1.7.4 installed. All packages are up to date. I've fixed a couple of issues that have been mentioned in other threads.

I'm migrating from an old CentOS 7 server that's been upgraded to iRedMail 1.7.4 in preparation for the migration.

I've got all my required customizations copied over and have an rsync job to keep /var/vmail/vmail1 synced to the new server. The final steps are to pause the firewall rules allowing the connection, do one last rsync of /var/vmail/vmail1, then a back and restore of the databases followed by updating DNS and the firewall rule and turning it back on.

What I'm now seeing on the new Rocky Linux 10.1 server is bursts of the following messages:

Nov 30 11:32:07 harrison systemd[1]: Looping too fast. Throttling execution a little.

The messages will continue for a while and then stop, Over the past 11.5 hours I've had 5044 of the messages.

I don't see any other errors and using journalctl to check each of the services I don't see any of the services leading to this. The only thing showing these errors is init.scope so nothing to point out what's causing this.

I've got another fresh Rocky Linux 10.1 install that doesn't have iRedMail installed and don't see the error so I suspect the errors are from some component of iRedMail.

Is anyone else running Rocky Linux 10.1 (or 10) with iRedMail 1.7.4 seeing these errors? I'm hesitant to do the final cutover if there's a potential problem. The only references I can find to this are several years old and for RHEL 7/CentOS 7/Ubuntu/Debian.