After a mail server was upgraded from Debian 11 (Bullseye) to Debian 12 (Bookworm), everything seemed to work. Mails came in, mails went out, Dovecot IMAP and POP3 continued to work smoothly.
But - of course there's a but - one thing caught my eye in our monitoring: The SpamAssassin service.
To understand the monitoring alert, we first have to look at what script is used in the background. In this particular example, a Perl script (check_spamd.pl) is used for this purpose. Executing the script manually shows the same error:
root@mail02:~# /usr/lib/nagios/plugins/check_spamd.pl
Input/output error
On Debian 10 and 11 the SpamAssassin service, a widely used open source software to detect spam mails, can be installed through the spamassassin package. Was the package accidentally removed by the upgrade?
root@mail02:~# dpkg -l|grep spam
ii spamass-milter 0.4.0-2 amd64 milter for filtering mail through spamassassin
ii spamassassin 4.0.1-1~deb12u1 all Perl-based spam filter using text analysis
ii spamc 4.0.1-1~deb12u1 amd64 Client for SpamAssassin spam filtering daemon
No, the package is still there. Yet the mail logs (/var/log/mail.log) confirm there's a problem forwarding the mails to the local Spamassassin service (using spamd):
mail02 spamc[2178]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
mail02 spamc[2178]: connect to spamd on ::1 failed, retrying (#2 of 3): Connection refused
mail02 spamc[2178]: connect to spamd on ::1 failed, retrying (#3 of 3): Connection refused
Did the service just stop or ran into an error during restart?
root@mail02:~# systemctl status spamassassin
Unit spamassassin.service could not be found.
Furthermore it also turns out that the spamd (used for the service/daemon) has disappeared as well:
root@mail02:~# ls -la /usr/sbin/spamd
ls: cannot access '/usr/sbin/spamd': No such file or directory
What ... the ... ?! Why is this service gone?
As it turns out, with the upgrade to Debian 12, the Spamassassin service/daemon (which also includes the /usr/sbin/spamd binary) was moved from the spamassassin to the spamd package.
Let's install this package and see what happens:
root@mail02:~# apt-get install spamd
[...]
Unpacking spamd (4.0.1-1~deb12u1) ...
Setting up spamd (4.0.1-1~deb12u1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/spamd.service -> /lib/systemd/system/spamd.service.
And right after, the spamd service was started. The log output also shows the familiar child states of the spamd (previously spamassassin) service processes:
root@mail02:~# systemctl status spamd
o spamd.service - Perl-based spam filter using text analysis
Loaded: loaded (/lib/systemd/system/spamd.service; enabled; preset: enabled)
Active: active (running) since Thu 2026-06-04 08:58:53 CEST; 11s ago
Main PID: 2348 (spamd)
Tasks: 3 (limit: 154370)
Memory: 113.6M
CPU: 2.408s
CGroup: /system.slice/spamd.service
|-2348 /usr/bin/perl "-T -w" /usr/sbin/spamd --pidfile=/run/spamd.pid --create-prefs --max-children 5
|-2358 "spamd child"
|-2359 "spamd child"
mail02 systemd[1]: Started spamd.service - Perl-based spam filter using text analysis.
mail02 spamd[2348]: spamd: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783>
mail02 spamd[2348]: spamd: server pid: 2348
mail02 spamd[2348]: spamd: server successfully spawned child process, pid 2358
mail02 spamd[2348]: spamd: server successfully spawned child process, pid 2359
mail02 spamd[2348]: prefork: child states: IS
mail02 spamd[2348]: prefork: child states: II
And what about the monitoring check? The Perl script now works:
root@mail02:~# /usr/lib/nagios/plugins/check_spamd.pl
OK - 0.279s response time
And therefore monitoring turned green again.
Mails are now forwarded from Postfix to Spamassassin (spamd) again.
That was a weird hiccup, luckily we have thorough monitoring in place to catch this. I would have anticipated, the spamassassin package upgrade would automatically install the (now needed) spamd package as dependency.
Taking a closer look into the package contents of the spamassassin package on Debian Bullseye reveals that the spamassassin service and the /usr/sbin/spamd binary were indeed part of this package:
[...]
/lib/systemd/system/spamassassin.service
/usr/bin/sa-awl
/usr/bin/sa-check_spamd
/usr/bin/sa-learn
/usr/bin/sa-update
/usr/bin/spamassassin
/usr/sbin/spamd
/usr/share/doc/spamassassin/CREDITS.gz
/usr/share/doc/spamassassin/NEWS.Debian.gz
/usr/share/doc/spamassassin/NOTICE
[...]
But in Debian Bookworm, the file list of the spamassassin package no longer contain a Systemd service, nor the spamd binary:
[...]
/lib/systemd/system/spamassassin-maintenance.service
/lib/systemd/system/spamassassin-maintenance.timer
/usr/bin/sa-awl
/usr/bin/sa-check_spamd
/usr/bin/sa-learn
/usr/bin/sa-update
/usr/bin/spamassassin
/usr/sbin/spamassassin-maint
/usr/share/doc/spamassassin/CREDITS.gz
[...]
The same also applies to the spamassassin package of the current stable, Debian 13 (Trixie).
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Observability Office OpenSearch PHP Perl Personal PostgreSQL PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Znuny Zoneminder