Quanah Gibson-Mount:
> I've seen issues with postdrop for years, complaining that about permission
> denied errors, such as:
>
> postfix/postdrop[4158]: warning: mail_queue_enter: create file
> maildrop/768314.4158: Permission denied
>
> I'm not entirely clear why they occur.
Note: the permission error comes from the kernel, Postfix does not
make up stuff like that.
For mail submnission to work:
- the postdrop program must have set-gid permission.
- the maildrop directory must be writable by that group ID.
> It seems related to postfix being
> stopped while attempting to write to this location. When that happens, an
> orphan postdrop process is left behind, like:
>
> zimbra 26222 0.0 0.0 45828 4164 ? S 11:40 0:00
> /opt/zimbra/common/sbin/postdrop -r
Postfix is supposed to keep trying and log the warning for each
attempt, so that mail is not lost and someone will eventually be
alerted. If Postfix is stopped instead of retrying, then that is
another sign that some kernel-based "security" policy is interfering
with its operation.
> Is this a bug in postdrop itself? Should the master postfix processes wait
> until postdrop completes before shutting down? I.e., I'm not clear on why
> it loses its ability to write to the directory on shutdown.
Really, it is as simple as a user-land program that calls open()
and gets access denied by the kernel. If that is not 100% reproducible
then you have a flaky kernel, a flaky file system, or some "security"
system with a flaky implementation.
The master runs daemon processes, and postdrop is not a daemon,
therefore messing with the master daemon is unlikely to have a
useful effect.
Wietse
