• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Spamassassin installation error - Ubuntu 14.04

trialotto

Golden Pleskian
Plesk Guru
Installing Plesk Panel with Spamassassin on Ubuntu 14.04 LTS gives a significant error:

Restarting SpamAssassin Mail Filter Daemon: No /usr/bin/perl found running; none killed.
server socket setup failed, retry 1: spamd: could not create IO::Socket::INET6 socket on [::1]:783: Cannot assign requested address
server socket setup failed, retry 2: spamd: could not create IO::Socket::INET6 socket on [127.0.0.1]:783: Address already in use
....
server socket setup failed, retry 9: spamd: could not create IO::Socket::INET6 socket on [127.0.0.1]:783: Address already in use
spamd: could not create IO::Socket::INET6 socket on [127.0.0.1]:783: Address already in use
invoke-rc.d: initscript spamassassin, action "restart" failed.
dpkg: error processing package sa-compile (--configure):


even though spamassassin (i.e. spamd) is not running.

The usual suspects for the before mentioned error, being

a) differences in the name of the PIDFILE variable in /etc/default/spamassassin and /etc/init.d/spamassassin
b) directory and/or file location are not readable/writable

are not causing this specific installation bug.

The work-arounds:

1 - not installing spamassassin (not an option)
2 - installing spamassassin and (afterwards)
  • change /etc/default/spamassassin, add the option "-4" to the line OPTIONS, resulting in the line: OPTIONS="--nouser-config -4 --username=popuser --daemonize --helper-home-dir=/var/qmail --virtual-config-dir=/var/qmail/mailnames/%d/%l/.spamassassin --create-prefs --max-children=5"
  • run plesk-installer or autoinstaller again

Work-around 2 works fine, after reinstallation the /etc/default/spamassassin is as it should be (note that the added "-4" is not present anymore).

The before mentioned work-around suggests some error in the installation process, very likely to be an issue with the chronological order of installation of the various components.

In theory, it can be excluded that this bug/issue is caused by psa-spamassassin and/or spamassassin (version 3.3.x) packages, even though some current spamassassin bugs are known:

http://talk.plesk.com/threads/how-to-patch-spamassassin-dnsresolver-pm.332023/

I sincerely hope that Parallels Team can investigate and patch both of the bugs/issues.

Kind regards....
 
@IgorG,

The installation error is not really related to the SA "bug", given the fact that, after first installation failure, the /etc/default/spamassassin can be changed to contain the "-4" option and reinstallation will then yield a success (even though the same package from the OS vendor repo will be used!).

Moreover, a Plesk installation on Ubuntu 12.04 LTS with the identical SA packages does not result in the same installation errors, even though the SA bug is present.

In a sense, the failure to restart SA gracefully (i.e. without error notifications) is the cause of Plesk´s autoinstaller not installing spamassassin AND Plesk properly.

In theory, Parallels Team should be able to overcome this SA bug (in order to prevent Plesk installation errors) by

a) starting spamassassin "manually" with the options from step 2 in my first post, OR
b) adding a custom and non-writable /etc/default/spamassassin before installation of SA, with the options from step 2 in my first post, OR
c) enable IPv6.

Are there any objections to enable IPv6 by default?

Note that the SA bug is also related to a "time-out", in the sense that it has been implied (somewhere) on the Debian report logs that a stop and start with some interval could work, even though I personally did not find evidence for this solution in my tests (even though the suggested "relation with a time-out" seems to be correct).

Most important, note that a process of (in chronological order):

- installation of SA (resulting in error notifications regarding the restart)
- changing /etc/default/spamassassin to contain the "-4" option
- de-installation of SA
- re-installation of SA (not resulting in any errors AND the "standard" /etc/default/spamassassin, without the "-4" option)

results in a proper installation of spamassassin AND Plesk, hence suggesting that compilation errors (sa-compile) do not occur AND that a solution exists with

- an easy fix: change options at installation time (not sure whether the issue will re-occur with a new restart), OR
- a robust (simple) fix: supply an custom package with (only) a custom /etc/default/spamassassin file

and both solutions can be the fundament of a simple patch by Parallels team, besides enabling IPv6 by default.

In short, it is very unlikely that this specific installation error is related to the SA bug or compilation errors, while it is very likely that options are set incorrect.

Are there, in your opinion, reasons for a different view?

Kind regards....
 
@IgorG,

The workaround of adding "-4" to the OPTIONS line in /etc/default/spamassassin is also working when restarting xinetd afterwards (service xinetd restart).

In theory, the above implies that in the plesk installer process, the error notifications can be overcome and/or (even) prevented by (in sequence)

- installing spamassassin
- not starting spamassasin
- adding "-4" option to /etc/default/spamassassin
- restart of xinetd
- start of spamassassin

and, afterwards, spamassassin (i.e. spamd) can be started, stopped, restarted without any problem.

Note that this is a practical implication of a workaround, not a solution for the bug(s) in the spamassassin packages.

Also note that the workaround is required (!), since Plesk will not install properly, if errors are encountered in the spamassassin installation process.


Kind regards....
 
Back
Top