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

netgroup:       nis
----  END  ----

I wonder if any of the other people who have met this bug are using any other PAM or NSS beyond the basic local /etc/passwd and /etc/group files?