1
SmarterMail Enterprise 100.0.9210.28175 (Mar 20, 2025) Build 9210 memory leak
Problem reported by Scott Johnson - 4/3/2025 at 1:51 PM
Submitted
ALL versions created this year (2025) run on Linux (have not tested Windows in 2025) exhibit memory leaks.  We have had ticket open for months.  Current version is the worst of the group.  I have seen others post on this but it is not getting the appropriate attention.  When paid for software is having to be rebooted every 6 hours on a 64GB 20 core system there is an issue that should not be publish as a general release to the public.

What does it take to get this fixed?

36 Replies

Reply to Thread
0
Brian Bjerring-Jensen Replied
Do you have any addons running with smartermail?
2
Derek Curtis Replied
Employee Post
You're having this issue, but not every Linux user is having it. We're running Linux, and we're constantly updating with newer, non-public builds and whatnot, but our memory is fine. We have multiple other servers running Linux versions and they run fine.

So, it's something unique to your particular environment, or an account (or multiple accounts) or a domain, or a migration, or indexing, or something. That's why it's important for you to work with us and go through various troubleshooting steps. If we can replicate the issue(s) -- which we've been unable to do up to this point -- that goes a long way in helping us figure out the "why" of what's happening. 
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
Scott Johnson Replied
Your memory is not fine.  Server ran for years on windows.  There is an issue.  This is exactly the problem.  Watched many of these posts and the standard is to blame the user.

As to the question of addons.  Nothing from the marketplace, but it was a replacement for an Exchange sever so EWS/EAS/MAPI.  It is here where the memory issue is.  The more of these users the faster the memory goes. No POP or WebDav either.
0
Jay Dubb Replied
Scott, just a question, are you sure it's a memory leak and not just a ton of consumption from the EWS/EAS/MAPI protocols?  On a server with a little over 2,000 users, most using EAS and MAPI, we regularly saw memory consumption in the 80-90 GB range.  Things got a little better with the newer versions running later .NET framework versions, but the lowest on a regular weekday-- high 60s to mid 70s GB and there were no other apps or plug-ins running.  Just straight Smartermail and nothing else.
 
0
Scott Johnson Replied
Server crashes no matter the memory.  It has only 17 total users. Yes it is all related to  EWS/EAS/MAPI.  128 or 256G still consumes all memory and crashes. Consumes over 30gb of ram in 6 hours.  So far with support pulling all of the configs no one has found any of the alleged user configuration issues.  Running the DotNET garbage collection intervals as aggressive as possible makes no difference.  GC cannot recover leaked memory.  
4
Gabriele Maoret - SERSIS Replied
if your server crashes with only 17 users, it's really something weird in your environment...

We have thousands of users on 6 separate servers (hundreds of them using MAPI/EWS and EAS) and no problems at all with 32GB max on each server...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
0
Scott Johnson Replied
On Linux?
1
Gabriele Maoret - SERSIS Replied
actually no... 5 are Windows and only one is Linux.

Are your problems only with Linux?
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
0
Oliver Replied
@Gabriele, may I ask which hard disks you are using? HHD, SSD or NVMe and which RAID level?
1
Scott Johnson Replied
My original post says Linux.  Devil is in the details.

To be very clear.  New Debian install, new Smartermail install, migrated from an existing windows server per instructions of Smartertools.  Ran without issue.  As soon as MAPI/EWS and EAS were used with newly added domains the issue started.  Stop using those and the issue stops.

So the thing about Linux, not universal like windows.  This server is:

Description:    Debian GNU/Linux 12 (bookworm)
Linux version 6.1.0-32-amd64 (gcc-12 (Debian 12.2.0-14) 12.2.0
glibc Version: 2.36-9+deb12u10

This may or may not be the same as others.  It is also of interest that Smartertools has chosen NOT to install standard dotNet packages as instructed by Microsoft.  So every system is different.  Having now written software for over 40 years I can assure you that this is a memory leak.  It is at the core of MAPI/EWS and EAS.  It is reproducible.  It is predictable and after Smartertools looking at the server they could not find a configuration issue/error.  

This does not mean that others will experience the issue or that Windows servers exhibit the issue.  Windows and Linux memory management sub-systems are entirely different  All of the kernel work we did in Linux during the mid-2000s taught us that.  Much of the code we brough from other platforms to Linux had issues.  

When users purchase software, pay for maintenance and pay for support they should not be subjected to being the debug platform.  This type of issue would have caused a failing grade in my CS classes 43 years ago.  Free you get what you pay for.  It is great that that software is working on many platforms.  I hope that continues.

No user or environment issue should cause these.

Feb 01 22:41:43 mail kernel: .NET TP Worker invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
Feb 01 22:41:43 mail kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/smartermail.service,task=MailService,pid=817,uid=0
Feb 01 22:41:43 mail kernel: Out of memory: Killed process 817 (MailService) total-vm:309299092kB, anon-rss:30568144kB, file-rss:0kB, shmem-rss:153620kB, UID:0 pgtables:64220kB oom_score_adj:0


0
Matt Petty Replied
Employee Post
Could try adding some swap to the server, I think this is something I tried on some ubuntu servers just adding like 4gb/8gb helped a lot, its something windows has by default but later ubuntu/debians dont have it.
https://askubuntu.com/questions/178712/how-to-increase-swap-space
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
2
Gabriele Maoret - SERSIS Replied
@Oliver: all disks are NVMe Enterprise. We use VMs on RaidZ1 Storage in ProxMox Clusters
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
0
Brian Bjerring-Jensen Replied
0
Oliver Replied
@Gabriele: THX
0
Gabriele Maoret - SERSIS Replied
@Scott Johnson : I'm monitoring the only Linux distribution I have.
This is a new test installation with only two users enabled for now (more will be enabled in a week or two)...
I'll give you some updates in a few days (10-15)...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
1
Jason Replied

We're experiencing the same memory leak issue and are now on build 9224. We've had a support ticket open for over 5 months with no resolution. We're also running SmarterMail Enterprise, and originally reported the problem when our server was running Windows. Since then, we’ve migrated to Linux, but the issue still persists. It's extremely frustrating, especially given the lack of meaningful updates from support. I'm glad to see we're not the only ones noticing this. Hopefully, increased visibility here will help move things forward, as this is now holding up other server migrations.

0
Mart Vernik Replied
We are running SM at Debian 12, ~200 users, Monthly Avarage Hardware Usage at System Administrator Reports page shows 2GB. We currently have ~10 MAPI/EWS/EAS users. Don’t know if it makse differents but we are running Caddy in front of Kestrel.
0
Scott Johnson Replied
@Mart Vernik that is very different from the basic Smartermail install which uses the built-in web server.  However, it is a difference I did not think of when migrating from our Windows systems which were using IIS. 
0
Nathan Replied
We are running Debian 12 with build 9168 and confirm we are seeing a memory leak too with circa 200 users with IMAP/POP/SMTP based access (no EWS). Webmail is used but minimal. This is an old windows install moved to Linux earlier this year. This morning the smartermail service is using circa 15% of the RAM allocated to the system, last night it was 75%+. The drop was due the services being restarted, not memory management!
1
Brian Bjerring-Jensen Replied
Does this work?


Create a file called clear_memory.sh:
#!/bin/bash

# Clear page cache, dentries, and inodes
sync; echo 3 > /proc/sys/vm/drop_caches

# Optional: log the action
echo "Memory cleared at $(date)" >> /var/log/memory_clear.log
Make it executable:
chmod +x clear_memory.sh

Step 2: Set up a cron job to run it every 3 hours

Edit the crontab:
crontab -e
Add the following line:
0 */3 * * * /path/to/clear_memory.sh
This runs the script at 00:00, 03:00, 06:00, etc.

⚠️ Important Notes:

  • This operation requires root privileges. You’ll need to run the script as root or use sudo.
  • If using a regular user's crontab, prepend sudo (and make sure the user has permission):
0 */3 * * * sudo /path/to/clear_memory.sh
  • Alternatively, place the script in /etc/cron.d/ as a root-level job.
You can test it manually first:
sudo bash clear_memory.sh
6
Scott Johnson Replied
Smartertools support has now validated that there is memory leak. It took 3 months to get this treated with importance and looked at. Took one day to create a potential fix. Three months of work by a paying customer to convince people to spend the time to acknowledge and work on the issue. It should not be this way. Customers pay to use the software. Not debug it.

So Mr. Curtis, next time work the problem BEFORE you blame the customer.  It is not the right way to do support and Smartermail memory is not fine.
2
Brian Bjerring-Jensen Replied
Yeah and I am dealing with ongoing calendar issues and favorite folders dissappearing....

And it just keeps going.
2
Gabriele Maoret - SERSIS Replied
After a few days of testing and configuration, I can confirm that even on my Linux server (latest Debian, just installed from scratch) SmarterMail suffers from a memory leak problem (RAM tends to fill up even though I only have 5 users!!!), and that the problem is still present in the latest version 9229...

I hope this problem will be fixed ASAP, because it is really annoying.
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
2
Scott Johnson Replied
So if your server had this issue with only a few users there's must be something really weird in YOUR environment.....

LOL

Thank you for validating. That is above and beyond. For those that do not understand, there is no possible way for memory to be consumed until app crash without there being a bug. Standard OS memory management will not allow it and an user or admin cannot configure it to fail through any normal means.

My argument though is not that there should be no bugs. But rather the lengths, effort and time one must go too too get some attention to the problem for people who pay for a product. Pay for maintenance. Pay for support. SOP is the blame the user. 

This needs to change. FYI, the fix they gave did not fix it. Which means the bug they fixed is just one more.
4
Scott Johnson Replied
Smartertools,

In the world of today the next best thing, the rush of the new, the shiny object is getting in the way of the important.  Something that works is far more important than something new.

Please, refocus on stability and reliability then on to new.  I to have my list of new ( like public folders for mail ) but I will for go the requests for making sure what we have today works.

Thank you. 
1
Brian Bjerring-Jensen Replied
And now I have an email showing unread in my inbox... but outlook not showing anything.

Webmail is fine. So tell me that MAPI is working flawlessly....

1
Scott Johnson Replied
New guess at a solution from Smatertools:

"That's definitely unfortunate and potentially illuminating. I would be curious if we could try to do an uninstall and reinstall of SmarterMail and see how it performs after? If it doesn't have any really noticeable difference on impact, I would be curious to see if we could try switching from using the built-in web server over to nginx or Apache and see if the performance improves?"

1
Brian Bjerring-Jensen Replied
Yeah and waisting customers time troubleshooting their own product....
0
Gabriele Maoret - SERSIS Replied
I'm testing a custom version 9230 for Linux.
It seems to work fine so far...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
1
Ben Rowland Replied
I am interested to know the root cause of this issue. My understanding is that Windows and Linux versions should have identical .NET Core code, but apparently only the Linux version exhibits this problem (according to several who have posted about it).
1
Scott Johnson Replied
New version created and loaded to fix the leak.  We will see.
3
Scott Johnson Replied
So at this point three issues have been identified. Two appear to be resolved.  The last one is related to SMTP and shows under load.
0
Richard Laliberte Replied
Any word if the new 9238 build solves the memory leak issues? they don't specifically mention any other than "Efficiency: Multiple caching changes to reduce memory consumption." hopefully this build helps...
0
Scott Johnson Replied
I will validate but I know for sure two items not addressed.  EWS retrieval and SMTP under load. 
3
Scott Johnson Replied
All fixes i have are in the new released version
1
Ben Rowland Replied
I installed this version this morning as it has a gateway fix for me as well.

Reply to Thread

Enter the verification text