Control: tags -1 + moreinfo On Tue, Sep 23, 2025 at 11:18:50AM +0200, Jochen Pawletta wrote: > After server reboot spamd starts like this: > 2025-09-23T08:46:24.486881+02:00 joshua spamd[1304]: spamd: server started on > IO::Socket::IP [127.0.0.1]:783 (running version 4.0.1) > > A "systemctrl restart spamd" fixes that: > 2025-09-23T11:07:09.580392+02:00 joshua spamd[23568]: spamd: server started > on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version > 4.0.1) > > I also have this problem on two other servers. > > If you need more information please say so.
So, my first thought was that you were experiencing something related to bug #1111791, which I encountered and wrote about in a different context. [1] [2] However, I'm not sure that's the case. I tested this myself on a VM with a few different configurations. Even in cases where I never obtained global-scoped IPv6 addresses, spamd still listened on the ipv6 loopback interface. If you configure systemd-networkd-wait-online to wait for IPv6 connectivity, does it get better? Use a configuration like the following in /etc/systemd/system/systemd-networkd-wait-online.service.d/99-ipv6-wait.conf: [Service] ExecStart= ExecStart=/lib/systemd/systemd-networkd-wait-online --any --operational-state=routable --ipv6 If that works, you can leave that configuration in place. As described in #1111791, the default behavior is correct and isn't going to change. If that doesn't work, you could enable debug output from spamd and send the relevant output. The first 15 lines or so of output should indicate what it's doing. noah 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111791 2. https://noah.meyerhans.us/2025/08/29/determining-network-online-status-of-dualstack-cloud-vms/
