SpamAssassin won't start

I posted this on the forum, but I guess I should have posted it here. My bad.

After a kernel update & a Webmin update, I can't start SpamAssassin

/etc/init.d/spamassassin start

Oct 15 09:15:45.279 [9744] warn: server socket setup failed, retry 9: spamd: could not create INET socket on Address already in use Oct 15 09:15:46.281 [9744] error: spamd: could not create INET socket on Address already in use spamd: could not create INET socket on Address already in use

Have tried rebooting - no success.

Operating system:CentOS Linux 6.8 Webmin version:1.820 Virtualmin Pro version:5.04



Howdy -- hmm, that error makes it look like SpamAssassin may already be running.

What is the output of this command:

ps auxw | grep spam


ps auxw | grep spam

root 8800 0.0 0.0 103312 864 pts/0 S+ 21:04 0:00 grep spam

Hmm, that part looks good... how about this command:

netstat -anlp | grep :783

Thanks. For that I have:

netstat -anlp | grep :783 udp 0 0* 952/portreserve

Hmm, are you running a program/service called "portreserve"?

It looks like that is running, and is holding that particular port open.

It's something that seems to have appeared on my system just recently (!). /etc/portreserve is Sept 30. I'll see what more I can find out.

Yes, I can confirm the problem is with "portreserve" (TCP port reservation utility).

I looked at my CentOS 7 server, and that's fine, and is not using Portreserve (yet? see below!)

Then I powered up a Centos 6 test server with almost identical configuration to my production server (but GPL). Sure enough - same problem!

If I use Webmin to stop the Portreserve process, SA starts again just fine. It looks to me as though this 'TCP port reservation utility' came in on the back of a recent CentOS 6 update, so there may be others with this issue soon?

So the thing is - is there something in the SpamAssassin config that needs tweaking? Or is it best to just ditch Portreserve? I'm guessing the folks at Redhat introduced it for a reason, and maybe it makes sense long term to stay consistent with them? The quick & dirty easy fix isn't always the best solution!

Great, I'm glad that helped!

I'm not quite sure why that's an issue now, and we hadn't run into that in the past... but as you suggested, we'll keep our eyes open for similar issues moving forward. If RedHat or CentOS did indeed make some changes along those lines it's likely to cause problems for others.

Out of curiosity, is your server a dedicated server, or a VPS?

As far as how best to resolve this for the long-term --

I'll be honest, prior to your request here I didn't actually have any experience with portreserve previously. So I had to do some digging to try and sort out what exactly it is.

So far as I ran tell, it's a tool for ensuring that Portmap and Cups work properly. And that, for folks not using either of those, it should be safe to disable entirely.

I did find an example of someone who was seeing your issue here:

It sounds like there is a command that's run, "portrelease spamd", prior to SpamAssassin starting, that is supposed to tell the portrelease program to stop holding SpamAssassin's port open.

Unfortunately, after reading the whole thread I'm not really sure I understand the cause of the problem still. But perhaps manually running that command will show more information.

Personally though, if you aren't running NFS or using Cups I'd be inclined to disable it :-)

Thanks. Yes I'll think I'll go with disabling portreserve!

(My server is a dedicated server)