Hello LenLynch,
Thanks for this mail.
My comments are inside your answer.
On 07/02/2023 19:36, LenLynch wrote:
Thanks for the context.
This happens regularly, but you don't say if the times when the
external script runs, is before, during, or after the mail log errors
occur. Or maybe I'm not following what you are saying closely enough.
I don't see any correlation between the times when the external script
runs and the time when the errors occur. Before or after - it's
difficult to estimate as the script runs every 10 minutes.
You talk about expecting to see log errors (from the script?) which
you don't. Are the times when the external script runs, low
utilization times of the day, so that a stop/start of smtpd would be
tolerable?
As I mentioned, the script runs every 10 minutes (and I would like to
run it every 2-3 minutes), so I would avoid to restart smtpd so often -
probably some clients will hit the moment it's down.
If I were in your shoes, I would modify the senders-consul external
script to create a new file, instead of directly updating the table file.
Compare that new file to the old table file, and only if there is
reason to update it, stop smtpd, update the file and then start smtpd
again.
What you've done in this step is make sure that you have a
closed/complete replacement file, and you've determined that it needs
to be updated, and you are doing the simplest workflow to update it
possible.
Thanks for this idea, I'll try to modify my script to operate at more
'intelligent' way.
If something like that runs error free consistently, then you know
that the update of that file is the root cause.
Then consider if there are other workflow changes you want to do to
improve it.
As I said, the error comes /sometimes/, so even if I modify the script
and I have less errors - it does not mean that the root cause was the
table update...
Peter
