This comes up every once in a while, most recently in https://bugs.gentoo.org/646330
When amavisd-new reloads after dropping privileges, it reads its configuration files as the unprivileged "amavis" (or whatever you've set it to) user. Since that differs from the first time amavisd-new is started, it tends to catch people by surprise, especially considering how common it is to reload amavisd-new in the middle of the night after a SpamAssassin rule update. We can't expect any miracles: if the "amavis" user can't read its own configuration, the daemon's going to crash. But right now, it crashes silently, with no indication of what went wrong. This happens when amavisd.conf is unreadable, or when any of the map files mentioned inside amavisd.conf are unreadable. When someone flips the g-r bit on a postfix map file and amavisd-new crashes 12 hours later, it can be hard to track down what actually went wrong. It would be extremely helpful if amavisd-new could log "I can't read $whatever" before committing suicide =)
