unable to start

[Johan Smits]

I have an issue on Ubuntu 14.04 (upgrade from 12.04) that when I enable @bypass_spam_checks_maps = (%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
The service will not start (only in debug or in foreground)
I see no chrashlog any pointers?
I see only this in the syslog:

ay 5 21:01:42 misc01 amavis[27989]: starting. /usr/sbin/amavisd-new at misc01.leftclick.eu amavisd-new-2.7.1 (20120429), Unicode aware, LANG="en_US.UTF-8"
May 5 21:01:42 misc01 amavis[27989]: perl=5.018002, user=, EUID: 109 (109); group=, EGID: 113 113 (113 113)
May 5 21:01:42 misc01 amavis[27989]: INFO: no optional modules: Unix::Getrusage
May 5 21:01:42 misc01 amavis[27989]: SpamControl: attempting to load scanner SpamAssassin, module Amavis::SpamControl::SpamAssassin
May 5 21:01:42 misc01 amavis[27989]: SpamControl: scanner SpamAssassin, module Amavis::SpamControl::SpamAssassin
May 5 21:01:42 misc01 amavis[27989]: INFO: SA version: 3.4.0, 3.004000, no optional modules: Net::CIDR::Lite Encode::Detect Razor2::Client::Agent IP::Country::Fast Image::Info Image::Info::GIF Image::Info::JPEG Image::Info::PNG Image::Info::BMP Image::Info::TIFF auto::NetAddr::IP::full6 auto::NetAddr::IP::Util::inet_n2dx auto::NetAddr::IP::Util::inet_n2ad auto::NetAddr::IP::Util::inet_any2n auto::NetAddr::IP::Util::ipv6_aton
May 5 21:01:42 misc01 amavis[27989]: SpamControl: init_pre_chroot on SpamAssassin done
May 5 21:01:42 misc01 amavis[27989]: bind to /var/lib/amavis/amavisd.sock|unix, *:10024/tcp
and then the application stops...

When I run on a new 14.04 system it runs ok, but doing a reinstall is not an option due to DNS+ldap+domain controller etc...

It seems that there is some environment issue or cache files but I cannot find them.
For now running in screen in foreground modus.

What is the difference in running as a normal start or as a foreground/debug modus?

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: amavisd-new 1:2.7.1-2ubuntu3
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
Date: Mon May 5 19:55:18 2014
PackageArchitecture: all
SourcePackage: amavisd-new
UpgradeStatus: Upgraded to trusty on 2014-05-03 (2 days ago)
modified.conffile..etc.amavis.conf.d.50.user: [modified]
mtime.conffile..etc.amavis.conf.d.05.node.id: 2014-05-05T19:50:03.037855
mtime.conffile..etc.amavis.conf.d.15.av.scanners: 2014-05-05T19:50:02.629855
mtime.conffile..etc.amavis.conf.d.15.content.filter.mode: 2014-05-05T19:50:03.141855
mtime.conffile..etc.amavis.conf.d.20.debian.defaults: 2014-05-05T19:50:06.081856
mtime.conffile..etc.amavis.conf.d.21.ubuntu.defaults: 2014-05-05T19:50:02.725856
mtime.conffile..etc.amavis.conf.d.25.amavis.helpers: 2014-05-05T19:50:02.833855
mtime.conffile..etc.amavis.conf.d.50.user: 2014-05-05T19:50:02.937855

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Hugo Slabbert (hugo+ubuntu)]

I hit a similar issue. Happened to stumble across a forum post that pointed to a non-qualified hostname in /etc/hostname. On my new 14.04 install I found I actually *did* have a non-qualified name in /etc/hostname. I changed that to an FQDN, bounced the box, and amavis then started up fine.

Perhaps give that a shot?

[Hugo Slabbert (hugo+ubuntu)]

Scratch my supposed fix.; the service started up fine after the reboot, but failed after any subsequent restarts. I'm currently stuck running it in debug as well. Box was installed as 14.04 x64 from scratch; not a 12.04 upgrade.

$ dpkg-query --show amavisd-new
amavisd-new 1:2.7.1-2ubuntu3

uname is 3.13.0-43-generic

mail logs are similar:
Jan 11 22:24:02 bamboo amavis[5657]: logging initialized, log level 5, syslog: amavis.mail
Jan 11 22:24:02 bamboo amavis[5657]: starting. /usr/sbin/amavisd-new at bamboo.slabnet.com amavisd-new-2.7.1 (20120429), Unicode aware, LANG="en_US.UTF-8"
Jan 11 22:24:02 bamboo amavis[5657]: perl=5.018002, user=, EUID: 128 (128); group=, EGID: 138 138 (138 138)
Jan 11 22:24:02 bamboo amavis[5657]: INFO: no optional modules: Unix::Getrusage
Jan 11 22:24:02 bamboo amavis[5657]: SpamControl: attempting to load scanner SpamAssassin, module Amavis::SpamControl::SpamAssassin
Jan 11 22:24:02 bamboo amavis[5657]: SpamControl: scanner SpamAssassin, module Amavis::SpamControl::SpamAssassin
Jan 11 22:24:02 bamboo amavis[5657]: INFO: SA version: 3.4.0, 3.004000, no optional modules: Encode::Detect IP::Country::Fast auto::NetAddr::IP::full6 auto::NetAddr::IP:
:Util::inet_n2dx auto::NetAddr::IP::Util::inet_n2ad auto::NetAddr::IP::Util::inet_any2n auto::NetAddr::IP::Util::ipv6_aton
Jan 11 22:24:02 bamboo amavis[5657]: SpamControl: init_pre_chroot on SpamAssassin done
Jan 11 22:24:02 bamboo amavis[5657]: bind to /var/lib/amavis/amavisd.sock|unix, 127.0.0.1:10024/tcp

...then nothing, though amavisd-new runs fine in debug in the foreground as per original poster's report.

[John Edwards (john-cornerstonelinux)]

I have meet this problem with email servers that have been upgraded from Ubuntu 12.04 ("precise") to Ubuntu 14.04 ("trusty"). Amavis starts at boot and with the debug option, but fails to start via the init script or the command line ('sudo -u amavis strace /usr/sbin/amavisd-new start').

I have done some basic debugging and testing with different configurations:

1) Installing amavisd-new and spamassassin on clean install of Ubuntu 14.04, then enabling virus and spam check with:
@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

Allows amavis to be started and restarted cleanly.

2) Copying this configuration files in /etc/amavis/ to a machine that is effected by this bug does not fix the problem, so I conclude that the problem is not with the configuration files.

3) Purging and reinstalling the amavisd-new and spamassassin packages on an effected machines does not fix the problem.

4) On a fresh install of Ubuntu 14.04 (where amavisd was working) I installed and configured the machine to be similar to the machine where amavisd was not working. At each stage I checked that amavisd could be restarted via the init script.

After I installed and configured the slapd LDAP server and configured libnss and libpam to use it, then amavisd failed to restart. When slapd was stopped then amavisd could started, but if it slapd was running that amavisd will not start via the init script. Amavisd seems to run fine if it started before slapd. This was then also tested and confirmed on the original machine that had been upgraded from Ubuntu 12.04.

So this suggests that something in LDAP, PAM or NSS is causing amavis to fail to start. This is very odd because all the system accounts are in the local /etc/passwd and /etc/group files and should have nothing to do with LDAP users and groups. The amavis user is only a member of it's own amavis group, and the amavis group only contains the amavis and clamav users.

The LDAP configuration has 4 users and 19 groups created by the smbldap programs, and all of these are used by end-users and should not be used by the amavis user or group.

PAM is managed by the pam-auth-update system with LDAP configuration enabled:
---- START ----
$ grep -ir ldap /etc/pam.d/*
/etc/pam.d/common-account:account [success=1 default=ignore] pam_ldap.so
/etc/pam.d/common-auth:# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
/etc/pam.d/common-auth:auth [success=1 default=ignore] pam_ldap.so use_first_pass
/etc/pam.d/common-password:password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
/etc/pam.d/common-session:session optional pam_ldap.so
/etc/pam.d/common-session-noninteractive:session optional pam_ldap.so
---- END ----

Contents of /etc/nsswitch.conf:
---- START ----
passwd: compat ldap
group: compat ldap
shadow: compat ldap

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgrou...

[Hugo Slabbert (hugo+ubuntu)]

I'm also running slapd on the affected box. Similar setup:
- amavis user and group are local
- only end user users and groups in ldap

Checking back a bit further in the logs, I did also find this in syslog:

Jan 11 21:59:06 bamboo amavis[2820]: nss-ldap: do_open: do_start_tls failed:stat=-1

I'm out at the moment but will check further this evening if perhaps there are some TLS issues to clean up with slapd on that box that could be causing amavis issues.

[John Edwards (john-cornerstonelinux)]

Yes, I also have a few error messages containing "amavis[1533]: nss-ldap: do_open: do_start_tls failed:stat=-1".

Removing "ssl start_tls" from /etc/ldap.conf allows amavis to start. So the problem looks to be when amavis checking libnss when it is set to use LDAP with STARTTLS.

The TLS certificates used by the LDAP server are signed by the company CA which is set in the tls_cacertfile option in /etc/ldap.conf. They work fine when using "getent password" and other commands. The same certificates also work fine in Ubuntu 12.04.

Setting libnss to not check certificate by adding "tls_checkpeer no" to /etc/ldap.conf to not change behaviour.

[John Edwards (john-cornerstonelinux)]

Also tried SSL with LDAPS on port 636, but still the same problem.

[John Edwards (john-cornerstonelinux)]

Also tried the latest Debian package of amavisd-new (version 2.10.1-1) and that has the same problem.

[John Edwards (john-cornerstonelinux)]

CORRECTION: After updating the configuration and reverting to debugging options I think the latest Debian package of amavisd-new (version 2.10.1-1) will run when STARTTLS is enabled in /etc/ldap.conf. Needs more testing.

[John Edwards (john-cornerstonelinux)]

Reverted to an earlier snapshot of the virtual machine I was testing amavisd on, then installed the latest Debian package of amavisd-new (version 2.10.1-1) and can confirm that this works.

Could this be a candidate for a backport release?

Although I am still not sure of the cause of this bug.

[Hugo Slabbert (hugo+ubuntu)]

Similar to John, I can confirm 2.10.1-1 from Debian also runs without issue on my setup (thanks to John for the pointer and a bunch of the digging on this one).

[Andre Schlegel (andre-schlegel)]

Similar Problem with BackupPC un Ubuntu 14.04:

http://sourceforge.net/p/backuppc/mailman/backuppc-users/thread/alpine.DEB.2.10.1505121831320.27187%40diaspar.physics.unc.edu/#msg34107271

Removing "ssl start_tls" from /etc/ldap.conf allows BackupPC to start. Both applicaions using perl:

perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi