From: Trevor J. <Trevor@Videlicet.com> - 2010-09-16 14:38:46
|
I was away for a week, and was told by users that SMTP stopped for them some time before midnight on Tuesday evening. I tried going back to .09 and .08, but it did not work, so I used a Time Machine backup of settings from Tuesday ten days ago (I LOVE Time Machine for this). The server seems to be processing SMTP connexions again. Phew.... FWIW, I noticed in the Connections window that SMTP communications appeared to have started, but had somehow stalled for some reason. I went back to the initial notice about version .10 and noticed a new perl module requirement. MAYBE there was a versioning conflict, so I am in the process of upgrading the modules as I type this. If I find anything, I'll report it. I've had similar problems before, when the automated update starts with a new, but problematical, version. I've no way of knowing until one of my users bleats, or I notice my mailing has problem. As a result, I've decided to turn off automatic updates, because this 'phantom' failure mode has happened several times before (as a result of various causes in the betas), and I can't afford to have this happen again to an otherwise stable assp. Yes, I now realise that it's best to stop automatic updates when I'm away, but I also realise that there may be a better way to handle the automatic updates. If the new version requires a new version of a perl module and that version is not available (and the respective setting of assp is set to use the function that calls the perl module), then, Thomas had said in earlier instances of this problem at least a year ago, assp should simply disable those functions. Admittedly, this means both comparing the perl versions and whether the settings of assp use the perl modules. It's not really a problem for manual upgrades, since assp can reasonably require that we RTFM. This is not easily done for automated updates of assp. I've no doubt that the conundrum is as frustrating to Thomas as it is to users. :-/ HTH, T. |