This is a discussion on Re: Shared queue directory & pid for 2 postfix within the mailing.postfix.users forums, part of the Mail Servers and Related category; Hello all, Victor Duchovni wrote: > > You may not share a single queue directory between two Postfix instances. > ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Hello all,
Victor Duchovni wrote: > > You may not share a single queue directory between two Postfix instances. > If you follow this rule, no conflicts will occur. > > You may share a /var/spool/mail directory (with appropriate mbox locking), > or a maildir hierarchy (no locking required even with NFS). In other words > share the user mailbox store, but DO NOT share the MTA queus. Thanks a lot for your quick (and sharp !) answer, Victor. Yes in fact you are right and we are likely to have 2 different queue directories for our 2 postfix. And BTW it solves the point of the pid. But in our specific context of cluster, how can we manage the possibility of a realserver crashing ? In this case the queue directory on the NFS disk will become "orphan", and if the realserver cannot be rebuild quickly (I mean in about one hour), all the e-mails in queue just before the crash will be holding forever... Not really acceptable for a HA-cluster for our users... Is there a simple way to ask the postfix of the other realserver, alive and treating its own queue, to flush (I do not mean erase, but recover for him and bring back to its queue in order to try to deliver) the orphan queue directory of the dead postfix ? I like to think we cannot be alone having this cluster problematic... :-/ Thanks again for your help, best regards, Laurent. -- ################################################## ########### # Laurent Neiger | Centre Reseau & Informatique Commun # # | Tel. : (0033) (0)4 76 88 79 91 # # | Fax : (0033) (0)4 76 88 12 95 # # | Web : http://cric.grenoble.cnrs.fr # # CNRS Grenoble | mailto:Laurent.Neiger@grenoble.cnrs.fr # ################################################## ########### |