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 =)

Reply via email to