[BUG] no mechanism to automatically clean up master.pid after postfix pod crash about helm-charts

[micw]

It should. There was a discussion about it in mailu chat a few weeks ago and an (already closed) issue at Mailu/Mailu#1483. Please post to that issue if it's reproducible for you.

[micw]

(closing it here, we will track this in Mailu/Mailu#1483)

[micw]

Solution can be easily done. If postfix is running on the PID file, the file is locked. So on startup we can simply test if that pidfile exists. If so, we do

flock -n master.pid rm master.pid

This command removes the pid file if it's not locked (meaning no other postfix instance running on it), otherwise it fails.

[justinasjaronis]

Great to hear. I believe this should be added in [postfix]/start.py right before os.system("postfix start-fg"). Or should we run this command somehow with kubernetes?

However I see another very related issue is with concurrent postfix instances as mentioned in #53 , if we'd decide to scale number of postfix workers, current partition layout with shared /queue wouldn't allow to do that. shouldn't whole /queue directory be regular volume for the pod, not a shared one, mounted from main PVC ? I believe this change would allow to start unlimited number of postfix workers.

I also understand that if we go this route before termination of a pod, postfix queue should be emptied, otherwise we would have data loss of received-but-not-yet-processed emails.

[justinasjaronis]

Apart Your proposed cleanup command, IMHO that from kubernetes perspective /queue/pid folder should be not mounted from any volume. When Kubernetes restarts pod, it expects clean state of the container. Moving folder with PID files to any persistency is opposite to the best practices of Kubernetes and I don't see any reason why /queue/pid would be useful outside the container.