Bug 218216 - spamd frequently can't bind to port 783
spamd frequently can't bind to port 783
Status: CLOSED DUPLICATE of bug 103401
Product: Fedora
Classification: Fedora
Component: spamassassin (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
Depends On:
  Show dependency treegraph
Reported: 2006-12-03 11:47 EST by chris
Modified: 2008-05-01 11:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-10 10:30:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description chris 2006-12-03 11:47:11 EST
The default startup priority for nfslock is 14, and for spamassassin is 78. 
This means that rpc.statd is started up before spamd.

I'm regularly finding that rpc.statd decides to bind to port 783, which then
means spamd is unable to bind to that port and exits with "spamd: could not
create INET socket on Address already in use".  This in turn
means I get swamped with spam!

I'm not sure whether this is primarily an issue with rpc.statd or with
spamassassin, but it'd be good to be able to persuade rpc.statd not to steal
that port before spamd gets a chance to bind to it.

Is this occurring because spamd doesn't have an entry in /etc/services, or would
that make no difference?

Changing the startup priorities so that spamd starts up before rpc.statd would
be a workaround, but it's a hack.  There must be a better solution.

Using spamassassin-3.1.7-1.fc6 and nfs-utils-1.0.10-4.fc6.

Comment 1 chris 2006-12-10 10:30:04 EST
Sorry - just realised this is effectively a duplicate of bug #103401 (which was
opened over 3 years ago...)

*** This bug has been marked as a duplicate of 103401 ***

Note You need to log in before you can comment on or make changes to this bug.