Sorry; where do you see SM v. 7978?

Latest stable seems to be 7957...

7978 was online/available as download for a very short period of time, including ReleaseNotes/Changelog. I saw it last Friday n the morning/(Germany/local time), I thought about installing it Friday afternoon - but then this build was not available anymore for download.

So we should better wait until a new public release.
@Stefan: perhaps you should try downgrading to 7957 that is curently available as public-release at download-page. Good luck.

We saw our production server moon to 100% cpu. We are not sure if it's related to this update or if this is one of the illusive CPU issues that some customers have been seeing intermittently over the past couple weeks. In either case we decided to pull it (7978) until we can evaluate what exactly occured. This was on Thursday, our server has been running smooth since so we'll see what we can identify from that cpu issue and think of options.

The logging OP has pointed out was recently added to help us identify SMTP connections that were being aborted early before we could accept the DATA/Message. We will now not "OK" or deliver the message if they disconnect during the DATA command without us telling them OK first.

Hello Matt,

When we saw the new release and that in the changelog it was addressing DKIM issues it seemed very important for us to do the update without waiting as there was many posts about DKIM issues and that we were ourselves having some issues with DKIM and different customer domains.

So we are now running 7978 since 5th november.

During the night after the upgrade, the CPU went 100% and services were unavailable. We had to restart the service in emergency.

Today it had to be restarded again due to the same issue.

[rant]

As you were aware of this issue, I find it extremly unprofressional to silently remove the release after publishing it and not giving a warning to your customers that it can possibly have an issue that you are aware of.

I can't believe what I'm reading here!

You could at least inform of the issue with a community post or at least leave the release changelog online, remove the download link and add a warning to the changelog about the issue. But here you just silently hide the issue. What method is this really?

Also in different post Kyle suggested that we shouldn't downgrade a SmarterMail once it was updated to a new build due to possible issues, but it seems that yourselves are downgrading to resolve issue of new build ?

Should we then downgrade too ?

Really again, we are surprised on what you did here. Removing the download link I can understand, but hiding completly the existance of the release like it never existed... o_O

[/rant]

PS: I did a dotTrace the 2nd time it went 100% cpu and out of control. I can upload it to you if it helps finding the issue. If so please tell me where I should upload it.

@Sébastien Riccio We only put the warning to not downgrade on certain builds. You can see an example of the last one from a July build.

Unless specifically noted in the release, you can downgrade to the previous version. We also did not downgrade as we want the issue to occur though we did pull the release from public download.

If you could open up a channel with a ticket with support and let them know it relates to the build we didn't release. That would be immensely helpful as we were not able do obtain a dottrace and we have not had it happen again since the night it occured. Post here if you end up submitting that trace, I will go digging for it.

Hi all,

all your discussion doesn't solve my problem. I agree with you because I also was wondering that this new build isn't available any more without any information why.

Until build 7957 the SQL Backup Master tool was able to send mails. With 7978 I get the error in the SMTP log file. So I think this is an issue by the new SmarterMail version.

This!

Matt,

About the downgrade, I'm sorry but in another post for another issue we were told this :

So it's confusing to be told one thing here and the opposite there...

I've submitted ticket 25C-291C137E-0B1B with a link to download the dotTrace.

Thanks

Hello Matt,

A litle update on the 100% CPU topic. It happened 4 times after the update to build 7978 (I took two dotTrace that I send you). So we decided to downgrade to 7957.

But.. it happened again even after the downgrade.

That is very strange because it all started when 7978 was installed and now we can't get rid of the issue even with a downgrade. Is that possible that 7978 broke something that is persistant even after a downgrade. Maybe some change in data files ? As the changelog disappeared, I don't remember what were the changes (except some DKIM stuff).

@Sébastien: Did you reboot of the server before the uninstallation of 7978, then uninstall build 7978- and then again a server-reboot before installing the prior 7957 - and I would suggest a final reboot after installing 7957.

If I remember right there were a few times issues/rare conditions in the past with files that could not be replaced correctly. Since over a year I always use therse steps with "server-reboot" before uninstallation and after uninstallation - and even a server-reboot after installation of updated or downgraded build. I know it is a little bit time-consuming - but I am trying all to avoid any issues with "locked/blocked" files during uninstallation and/or installation.

Let us hope that Matt figures out what is going wrong by analyzing your dotTraces.

Hello Thomas,

Well when it's an emergency downgrade or update, we avoid to reboot the server, especially when there are windows updates pending because it can sometime take ages and we can't really down the services for ten of minutes in the middle of a workday.

We try to keep the server reboots for planned maintenance during nights

It would be interresting though to know what files that are replaced during a SmarterMail upgrade and that would still be open after stopping the service and requiring a reboot to be replaced. Maybe some DLLs but if their not part of the system itself they should be unloaded at service stop I guess ?

A log of the installation process that would containt the information about what files replacement triggers the "need system restart" would maybe be a good thing to consider if the reboot is really needed or not.

Kind regards

Surprisingly (and possibly entirely unrelated), we saw a 'moon to 100%' CPU event on one of our SmarterMail servers on build 7957 just once in the past few days but it looks like it was related to Clam AV as a restart of SmarterMail and the Clam AV service fixed it. We had updated to 7957 in hopes of fixing DKIM issues as well but the surprising aspect of this is that it's a server that typically runs at 20% of CPU with plenty of memory and has never once done this in the past.

@SmP Just curious what build you were on prior to 7957? I just wanna get a range of what was changed, might help figure out what change may have caused it.

Trusty 'ole 7950 but we had some complaints about issues with DKIM so when we saw the note in 7957, instead of waiting our normal several weeks, installed it. Since the 100% incident, haven't seen any activity since (and it was at least a couple of weeks following the install that it took place so it may be an uncapturable outlier completed unrelated as it never repeated that behavior). No abnormal indexing or odd activity was taking place at that time and it's a system completely dedicated to SmarterMail that has never had a history of this behavior.

I don't know if this is related or not... we are only on build 7906 (was planning to upgrade next weekend to latest), but we are seeing the tell tale saw-tooth pattern of a severe memory leak.

We started tracking memory usage back in June via PRTG when we were having crash issues when memory would max.  Now the system seems to recover, but not more than 20 minutes ago it reset the SmarterMail service all on its own.

That's interesting Rod, though I'm not sure it is related. Can you try upgrading to our latest to see if this keeps up? If it does I'd love to get some DotMemory snapshots done with you. 

Yeah, will see what I can do Kyle.   

I got a "no-go" for the update this weekend, so will see what comes of it the following weekend.

Sorry for the delay, out of my control.

No worries Rod, let us know if you need anything along the way.

Hi all,

updating to the latest build 8025 doesn't solve this issue. In the last days it worked only 2 times: First time with build 7978 on 19.12.2021 and second time with build 8025 on 23.12.2021. I updated SmarterMail on 22.12.2021. The errors of the log are still the same.