For example, a Microsoft Outlook client running on Windows 7 would report:

Receiving reported error (0x800CCC1A) Your server does not support the connection encryption type you have specified. Try changing the encryption method. Contact your mai server administrator or Internet service provider (ISP) for additional assistance.”

Despite the minor version number increment, Dovecot 2.4 is a major update which has significant breaking changes to the structure of the configuration files and thus the old configuration files need to be carefully converted in order to work with Dovecot 2.4.

Dovecot 2.4 should really have been called Dovecot 3.0. I have no idea why Open-Xchange considered a minor version number bump to be appropriate for this release.

The default TLS ciphers enabled for Dovecot (both 2.3 and 2.4) on cPanel are:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES256-GCM-SHA384

This is almost identical to the very useful Mozilla “Intermediate” list, except that the DHE-RSA-CHACHA20-POLY1305 cipher is missing.

Windows 7 has very poor support for modern cryptography since it went end-of-life in January 2020 and so hasn’t received any updates for 6 years now.

The supported cipher suites advertised in the SSL/TLS handshake by a Windows 7 client device are:

Most of these are now considered insecure and thus are not enabled on the server side.

The overlap between the TLS ciphers supported by the client and the TLS ciphers which are allowed on the server side is just four ciphers:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256

Unfortunately, the two ECDHE-ECDSA-* ones will only work if you are using ECDSA SSL certificates. If you are using RSA certificates then you can only use the DHE-RSA-* ones.
Still, we have TLS ciphers which are supported by both the client and the server so this should be working… why isn’t it?

Previously under Dovecot 2.3, cPanel had the following configuration in /etc/dovecot/dovecot.conf for the Diffie-Hellman parameters file necessary for the DHE-RSA-* ciphers to function:

# SSL DH parameters
# Generate new params with `openssl dhparam -out /etc/dovecot/dh.pem 4096`
# Or migrate from old ssl-parameters.dat file with the command dovecot
# gives on startup when ssl_dh is unset.
ssl_dh = </etc/dovecot/dh.pem

In Dovecot 2.4 this configuration directive changed to “ssl_server_dh_file” (see https://doc.dovecot.org/2.4.2/installation/upgrade/2.3-to-2.4.html#converted-settings) and it isn’t present anywhere in /etc/dovecot/ post-upgrade on cPanel servers.

As a random, aside; the old configuration “ssl_dh” option value was for the contents of the certificate, which could be read from a file with the redirect. The new “ssl_server_dh_file” option takes file path as the value, which Dovecot then reads itself. As such, when moving from 2.3 to 2.4 it’s important to ensure that you don’t copy over the less than symbol that precedes the path, otherwise Dovecot will try to read the contents of that file and treat those as the path that it should use.

In order to add the configuration for the Diffie-Hellman parameters file to the Dovecot 2.4 configuration yourself, you will need to make use of the cPanel configuration file templating system, otherwise any manual changes to the configuration files in /etc/dovecot/ will get overwritten the next time cPanel regenerates them.

First check if the /var/cpanel/templates/dovecot/main.local file already exists (for example if you already have custom Dovecot configuration or if you are using Imunify360). If not, then copy the file /var/cpanel/templates/dovecot/main.default to /var/cpanel/templates/dovecot/main.local and edit it in your favour editor to add the following configuration to the bottom of the file:

# Required for DHE-RSA-AES128-GCM-SHA256 and DHE-RSA-AES256-GCM-SHA384 ciphers needed for Windows 7 clients to work
ssl_server_dh_file = /etc/dovecot/dh.pem

Once you have modified the /var/cpanel/templates/dovecot/main.local file, you can run “/scripts/builddovecotconf” to regenerate the configuration files from your new template, followed by “/scripts/restartsrv_dovecot” to restart the Dovecot service.

IMAP and POP3 clients running on old devices such as Windows 7 should once again be able to connect as the DHE-RSA-* TLS ciphers that they rely on are functioning again.

The post cPanel Dovecot 2.4 upgrade breaking Windows 7 clients first appeared on Spheron1.

The first issue you will probably run into when trying to use the “ostor-s3-admin” command is the following error message:

Volume id (-V) must be specified

You can get a list of all of your volume IDs by running “ostor-ctl get-config -V“. This will give you something like the following:

VOL_ID             TYPE     STATE
0100000000000002   OBJ     READY

You can then specify the appropriate volume ID with the “-V” argument to the “ostor-s3-admin” command.

Another common error that you can run into is something along the lines of:

Request failed due to internal error
Command=list-user-accounts failed with error=8(Requested object not found)

Although the exact message that you receive will vary depending upon the command that you are trying to run.

This error is caused by not specifying a user account to execute the command as. I resolved this by grabbing the main admin account user ID from the ACI/VHI S3 admin web interface and passing that with the “-i” argument.
Alternatively you can use “-e” instead of “-i” and pass the email address of the user account that you want to run the command as.

Another rather vague and unhelpful error message that you may receive from “ostor-s3-admin” is:

Bad user management cmd

This actually means that you have the arguments before the command – the “ostor-s3-admin” utility expects to receive the command (e.g. “list-user-accounts” or “list-all-buckets“) before the arguments such as the volume ID and user ID/email.

So for example the full commands should be run as:

ostor-s3-admin list-all-buckets -V volumeid -i userid

Or:

ostor-s3-admin delete-bucket -V volumeid -i userid -b bucketname

Obviously you will need to replace “volumeid“, “userid” and “bucketname” with the respective values.

The “delete-bucket” command is a very handy one that seems to be missing from a lot of the ACI/VHI S3 documentation – it will delete the specified bucket along with all of the contents, unlike the admin web interface which expects you to empty the bucket yourself first. This does however take a very long time to run on large buckets.

The post Acronis Cyber Infrastructure/Virtuozzo Hybrid Infrastructure S3 admin command line first appeared on Spheron1.

Trying to use the “timescaledb-tune” utility (a key part of the installation process for TimescaleDB) on any Mac made in the last 5 years will result in an error unless you have the Rosetta 2 dynamic binary translation feature installed:

unable to execute /opt/homebrew/bin/timescaledb-tune: Bad CPU type in executable

This is particularly weird as the TimescaleDB library itself is ARM64.

Given that Tiger Data have had 5 years to ship a native ARM64 binary for their “timescaledb-tune” utility, it is rather disappointing to see that they are still relying on people installing the optional Rosetta 2 dynamic binary translation feature on their devices. This requirement also doesn’t seem to be documented anywhere that I can find.

Apple are going to be removing most of Rosetta 2 from macOS 28 in 2027, so hopefully Tiger Data will get around to shipping an ARM64 binary before then.

In the meantime, we can manually build an ARM64 binary for the “timescaledb-tune” utility from source as follows:

1. Download the Go installer from https://go.dev/dl/ using the “Apple macOS (ARM64)” option and run through the installer steps.
2. Open up your preferred terminal app and run “go install github.com/timescale/timescaledb-tune/cmd/timescaledb-tune@main”.
3. You will find the ARM64 binary for the “timescaledb-tune” utility in ~/go/bin/timescaledb-tune

I really don’t understand why Tiger Data aren’t shipping an ARM64 binary for their “timescaledb-tune” utility, given how ridiculously simple it is to build one!

The post ARM64 timescaledb-tune on macOS first appeared on Spheron1.

Setting up shim-signed (1.51.4+15.8-0ubuntu1) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.
mount: /var/lib/grub/esp: /dev/nvme1n1p1 already mounted or mount point busy.
dpkg: error processing package shim-signed (--configure):
 installed shim-signed package post-installation script subprocess returned error exit status 32
Errors were encountered while processing:
 shim-signed
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

The bizarre thing here is that the /dev/nvme1n1p1 device is nothing to do with the UEFI ESP, that lives on /dev/sdi1 as this particular server can’t boot from NVMe devices and so uses a small USB stick for /boot/efi and /boot instead.

The /dev/sdi1 device was mounted on /boot/efi as expected, and the UUID listed in /etc/fstab was correct, so initially I wasn’t sure where the reference to /dev/nvme1n1p1 for the UEFI ESP was coming from.
After a bit of digging I found that this was in fact caused by the /var/cache/debconf/config.dat file, which contained the following entry:

Name: grub-efi/install_devices
Template: grub-efi/install_devices
Value: /dev/disk/by-id/usb-SanDisk_Ultra_0401d75aeb6cd405701a2711e62657aae5100e05183ca1b9d69275564cee2e887ef5000000000000000000006c97162200805e188a5581075cac9e0f-0:0-part1, /dev/disk/by-id/nvme-eui.0000000001000000e4d25c49119f5401-part1, /dev/disk/by-id/nvme-eui.0000000001000000e4d25cb9029f5401-part1
Owners: grub-common, grub-efi-amd64, grub-pc
Flags: seen
Variables:
 CHOICES = /dev/nvme1n1p1 (1127 MB; ) on 512110 MB INTEL SSDPEKNU512GZ, /dev/nvme0n1p1 (1127 MB; ) on 512110 MB INTEL SSDPEKNU512GZ, /dev/sdi1 (1127 MB; /boot/efi) on 30765 MB Ultra
 RAW_CHOICES = /dev/disk/by-id/nvme-eui.0000000001000000e4d25c49119f5401-part1, /dev/disk/by-id/nvme-eui.0000000001000000e4d25cb9029f5401-part1, /dev/disk/by-id/usb-SanDisk_Ultra_0401d75aeb6cd405701a2711e62657aae5100e05183ca1b9d69275564cee2e887ef5000000000000000000006c97162200805e188a5581075cac9e0f-0:0-part1

I ran the following command to explicitly set it to the UUID of the filesystem on the /dev/sdi1 device:

echo "grub-efi-amd64 grub-efi/install_devices multiselect /dev/disk/by-uuid/47E1-19C4" | debconf-set-selections

Now the /var/cache/debconf/config.dat file contains:

Name: grub-efi/install_devices
Template: grub-efi/install_devices
Value: /dev/disk/by-uuid/47E1-19C4
Owners: grub-common, grub-efi-amd64, grub-pc
Flags: seen
Variables:
 CHOICES = /dev/nvme1n1p1 (1127 MB; ) on 512110 MB INTEL SSDPEKNU512GZ, /dev/nvme0n1p1 (1127 MB; ) on 512110 MB INTEL SSDPEKNU512GZ, /dev/sdi1 (1127 MB; /boot/efi) on 30765 MB Ultra
 RAW_CHOICES = /dev/disk/by-id/nvme-eui.0000000001000000e4d25c49119f5401-part1, /dev/disk/by-id/nvme-eui.0000000001000000e4d25cb9029f5401-part1, /dev/disk/by-id/usb-SanDisk_Ultra_0401d75aeb6cd405701a2711e62657aae5100e05183ca1b9d69275564cee2e887ef5000000000000000000006c97162200805e188a5581075cac9e0f-0:0-part1

After making this change, APT is happy again:

Setting up shim-signed (1.51.4+15.8-0ubuntu1) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.

I think this confusion was ultimately caused by some stray ESP partitions on the NVMe devices leftover from a previous attempt to install Ubuntu on this server.

The post APT/DPKG errors for shim-signed package first appeared on Spheron1.

Traditionally you needed an old copy of macOS Server in order to get these APNs certificates, but it was also possible to obtain the certificates using third party scripts such as https://github.com/scintill/macos-server-apns-certs which had reverse engineered the Apple APIs for issuing certificates.
Unfortunately, in October 2024 Apple discontinued this API and so it was no longer possible to issue new APNs certificates for com.apple.mail, com.apple.calendar and com.apple.contact.

Whilst it is annoying that we can’t provide push notifications to Apple users anymore thanks to these changes, this actually becomes a service affecting problem when these certificates expire as it causes any cPanel servers still using the old Calendar and Contacts Server (CCS) plugin (which behind the scenes is the old open source Apple/Darwin Calendar and Contacts Server) to break as the “cpanel-ccs” service will stop and refuse to start with a message about the expired APNs certificates:

-- Unit cpanel-ccs.service has begun starting up.
Apr 22 17:57:34 myserverhostname.com ccs_init[24103]: Using /opt/cpanel-ccs/.develop/virtualenv/bin/python as Python
Apr 22 17:57:34 myserverhostname.com ccs_init[24103]: Starting server...
Apr 22 17:57:34 myserverhostname.com ccs_init[24103]: /opt/cpanel-ccs/bin/caldavd  -f /opt/cpanel-ccs/conf/caldavd-dev.plist -P caldav -t Combined
Apr 22 17:57:36 myserverhostname.com ccs_init[24103]: Reading configuration from file: /opt/cpanel-ccs/conf/caldavd-dev.plist
Apr 22 17:57:36 myserverhostname.com ccs_init[24103]: APNS certificate expired /var/cpanel/ssl/caldav_apns/cert.pem
Apr 22 17:57:36 myserverhostname.com systemd[1]: cpanel-ccs.service: control process exited, code=exited status=1
Apr 22 17:57:36 myserverhostname.com systemd[1]: Failed to start Apple Calendar Server.
-- Subject: Unit cpanel-ccs.service has failed

Frustratingly, cPanel doesn’t provide a way to remove an existing APNs certificate, only to install new ones… given that no new APNs certificates can be issued, this leaves us rather stuck!
Sadly this kind of lack of attention to detail for basic management tasks is common throughout cPanel.

Even more frustratingly, cPanel seem to have removed all of their documentation about the APNs feature, so the only evidence that it ever existed are some very old posts on their badly mangled forum.

After a bit of poking around, I managed to find that you can manually remove the /var/cpanel/ssl/*apns/*.pem* certificate files and then update the CCS config in /opt/cpanel-ccs/conf/caldavd-dev.plist to remove any mention of them with the following commands:

rm -f /var/cpanel/ssl/*apns/*.pem*
/opt/cpanel-ccs/bin/rebuildccsconfig
systemctl restart cpanel-ccs.service

After this, the “cpanel-ccs” service will run normally again so CalDAV and CardDAV services are restored for all users.

The one last thing to do is go to Service Configuration -> Service Manager in WHM and disable “APNSPush” under “tailwatchd”.

The post Removing APNs certificates in cPanel first appeared on Spheron1.

The following was being logged in /var/logs/maillog for each attempt:

plesk sendmail[1628571]: handlers_stderr: ERROR:__main__:Rejecting message: system user uid='<user ID>’ is not allowed to send mail
plesk sendmail[1628571]: handlers_stderr: DATA REPLY:554:5.7.0 Your message could not be sent. The user <user name> is not allowed to send email.
plesk sendmail[1628571]: handlers_stderr: REJECT
plesk sendmail[1628571]: REJECT during call ‘limit-out’ handler

When calling sendmail from the command line, logged in as the user in question, I got:

Mail handler ‘limit-out’ said: REPLY:554:5.7.0 Your message could not be sent. The user logbookloans247 is not allowed to send email.

Plesk have a particularly useless knowledge base article which says that this is due to the mail service being disabled for the domain; https://support.plesk.com/hc/en-us/articles/360002410214-Unable-to-send-an-email-via-Wordpress-Rejecting-message-system-user-uid-xx-is-not-allowed-to-send-mail

This is nonsense – disabling the mail service is routine when email for a domain is hosted externally and so the server shouldn’t act as the final destination for email to this domain so as not to cause problems for any locally generated email destined for that domain.
Just to double check, I enabled the mail service on the domain, but unsurprisingly the problem persisted.

I checked several other Plesk servers and there were no other occurrences of this message in the mail logs, so this appeared to be an account specific problem.
I therefore tried fiddling with the outbound mail limits for the domain and the subscription, but no luck.

Eventually I stumbled on some users on the Plesk forums having a similar but unrelated problem, however this led me to the /usr/local/psa/admin/sbin/mailmng-outgoing command and through a bit of experimentation I found that the system user seemed to be missing, which I was able to add with the following command:

/usr/local/psa/admin/sbin/mailmng-outgoing --add-sysuser --main-domain-name=<domain name> --sysuser=<system user>

After doing this, sendmail and thus mail() worked as normal.

The post Sendmail on Plesk – user is not allowed to send mail first appeared on Spheron1.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).

After a quick rummage, I found that the reason was that the “LANG” environment variable on my laptop was defaulting to “en_GB.UTF-8”, whilst on the Ubuntu jump server it was “C.UTF-8”.

The cPanel server runs some Perl stuff when bash starts and if it doesn’t like your locale settings, then it spits out these warnings.

The “LANG” environment variable is part of the locale system and so the best way to fix this is to update the locale settings configured on the Ubuntu jump server.

By default, SSH on both macOS and Ubuntu is configured to send the local “LANG” and “LC_*” environment variables used for locale settings to the remote system.

You can use the “locale” command to see your current locale settings as well as “locale -a” to see installed locales.

$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=”C.UTF-8″
LC_NUMERIC=”C.UTF-8″
LC_TIME=”C.UTF-8″
LC_COLLATE=”C.UTF-8″
LC_MONETARY=”C.UTF-8″
LC_MESSAGES=”C.UTF-8″
LC_PAPER=”C.UTF-8″
LC_NAME=”C.UTF-8″
LC_ADDRESS=”C.UTF-8″
LC_TELEPHONE=”C.UTF-8″
LC_MEASUREMENT=”C.UTF-8″
LC_IDENTIFICATION=”C.UTF-8″
LC_ALL=

$ locale -a
C
C.UTF-8
POSIX
en_US.utf8

In my case I wanted to use en_GB.utf8, which wasn’t installed. You can use the “locale-gen” command to generate locales, but they are also provided in official Ubuntu packages , so I installed the “language-pack-en” package from the Ubuntu repositories using APT.
This added several English locales and then I could reconfigure Ubuntu to use the one that I needed.

$ apt-get install language-pack-en
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following additional packages will be installed:
language-pack-en-base
The following NEW packages will be installed:
language-pack-en language-pack-en-base
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 420 kB of archives.
After this operation, 3756 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en-base all 1:18.04+20180712 [419 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en all 1:18.04+20180712 [1904 B]
Fetched 420 kB in 0s (3606 kB/s)
Selecting previously unselected package language-pack-en-base.
(Reading database … 50814 files and directories currently installed.)
Preparing to unpack …/language-pack-en-base_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en-base (1:18.04+20180712) …
Selecting previously unselected package language-pack-en.
Preparing to unpack …/language-pack-en_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en (1:18.04+20180712) …
Setting up language-pack-en (1:18.04+20180712) …
Setting up language-pack-en-base (1:18.04+20180712) …
Generating locales (this might take a while)…
en_AG.UTF-8… done
en_AU.UTF-8… done
en_BW.UTF-8… done
en_CA.UTF-8… done
en_DK.UTF-8… done
en_GB.UTF-8… done
en_HK.UTF-8… done
en_IE.UTF-8… done
en_IL.UTF-8… done
en_IN.UTF-8… done
en_NG.UTF-8… done
en_NZ.UTF-8… done
en_PH.UTF-8… done
en_SG.UTF-8… done
en_ZA.UTF-8… done
en_ZM.UTF-8… done
en_ZW.UTF-8… done
Generation complete.

$ locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
$ update-locale LANG=en_GB.utf8

The locale settings are stored in “/etc/default/locale“, so you can either edit this file manually or use the handy “update-locale” utility to do it for you.
Either way, once you start a new session, you are using the new locale settings and Perl no longer complains when you SSH to a cPanel server.

The post Changing the locale in Ubuntu Server first appeared on Spheron1.

Anyway, the error message given by the OpenSSH client was:

Unable to negotiate with port 22: no matching cipher found. Their offer: des,3des-cbc

These ProCurves are pretty old and their SSH support is rather limited (1024 bit keys for example), so it’s not hugely surprising that their supported ciphers are also old and crappy.
Luckily, with OpenSSH you can specify the cipher(s) that you want to use on the command line when you’re connecting:

ssh -c 3des-cbc

This fixed the issue and lets me connect, but isn’t particularly convenient. However, you can also specify this in your ~/.ssh/config file so that it is applied automatically:

Host <blah>
Ciphers 3des-cbc

Just enter one or more hosts to match against (separated by spaces) and OpenSSH will automatically apply the specified options when connecting to any of them.

The post ProCurve SSH – no matching cipher found first appeared on Spheron1.

OLS is an open source derivative of the LiteSpeed Web Server (LSWS), which delivers most many of the key features, including the high performance LiteSpeed Cache (LSCache). Whilst it can’t read  Apache configuration files like its bigger brother LSWS (and thus can’t be used with a hosting control panel like cPanel or Plesk), it’s great for working with a handful of sites configured manually

Whilst the LSCWP plugin has a lot of useful features which can be used even without the LSCache from OLS/LSWS, the main selling point is the integration with LSCache to deliver blazing fast page load times along with massive scalability under load.

I recently ran into a bizarre issue where the cache just completely stopped working for no obvious reason, which led to hours of pulling apart WordPress and OLS to try and work out why.

Aside from pages loading very slowly, the main clue was that the X-Litespeed-Cache header was completely missing, although the X-Litespeed-Cache-Control header was present as normal. This would normally mean some kind of issue with the cache storage location (/usr/local/lsws/cachedata/ by default, unless override by the storagePath configuration option in the cache module settings).
I couldn’t see any issues with the cache storage location, but tried adjusting it elsewhere anyway without any luck.

I verified that all of the settings for the cache module were configured as per those listed on the OLS wiki and eventually out of frustration deleted the whole cache module definition from the server configuration and added it back, at which point the cache started working again!

I’ve absolutely no idea why removing and re-adding the exact same configuration should make any difference whatsoever, but I have now verified identical behaviour on two different servers with completely independent configurations.

The post OpenLiteSpeed WordPress cache mysteriously not working first appeared on Spheron1.

lua; bayes_expiry.lua:332: cannot perform expiry step: ERR Number of keys can’t be greater than number of args

The only reference that I could find to this online was a single post on the Rspamd mailing list, which had gone unanswered (https://groups.google.com/d/msg/rspamd/jFG-MTLzZw8/-8WIIY_ECAAJ).

It turns out that I had the “expire” setting defined twice in /etc/rspamd/local.d/classifier-bayes.conf. After fixing this, restarting Rspamd and waiting a couple of minutes, I started to see the expected log entries from the bayes expiry module executing its expiry processing step every minute:

lua; bayes_expiry.lua:368: finished expiry step 9995 (lazy): 1001 items checked, 163 significant (0 made persistent), 0 insignificant (0 ttls set), 0 common (0 discriminated), 838 infrequent (837 ttls set), 4 mean, 20 std

The post Rspamd, bayes expiry and Redis – ERR Number of keys can’t be greater than number of args first appeared on Spheron1.