> The script just does: > > * Copy in new relay_recipients file > * postmap relay_recipients > * postfix reload > > Is there a better way to do this? Should I stop postfix completely during > this time? Will putting the queue on hold avoid this problem, or do I need > to stop Postfix completely from responding? >
Brian, I know this is a late follow up, but I am doing the same thing, or getting ready to. Here is my general plan, with some questions. I will have two db files for each type (transport1, transport2, relay_recipient_map1, relay_recipients_map2, etc). The process will be similar to this: * Get the latest file as temp * Compare it to the last.type, same, then stop and go onto the next file * Which file do I need to update, 1 or 2. If 1 was last, then do 2, otherwise do 1. The file with the source size of 0 bytes with the candidate, if neither, default to 1. * Copy the temp file to the file I need to update * postmap the file I need to update * rename the file I need to update to last.type * any errors, stop, send email, go onto next file * zero the other file (not the db) * postmap the other file * repeat for each type I need to sync * wash, rinse, repeat every x minutes, assuming x might be 5 The general idea behind to files is that one will always have the full list, and the other will be the changing list. I want to clear the second file (the one that wasn't updated) when the one that was is finished as I don't want to traverse the databases twice (except for that short amount of time when it is creating the db). I was thinking about using postmap on the temp file and then doing the copy, but it's the same effect (as per the safe suggestions). If the file is being copied, then you can run into the momentary slice of time when the contents of the original file are null (though it's a much smaller amount of time). My questions: * Is this overkill? * Besides sometimes traversing the same hash twice, is there any other perceived issues with this ideology? * Or is the safe copy the best route?
