EWS hangs while gromox-http stays active

souverain · 2026-05-22T08:31:39+00:00

Hello, We encountered a temporary issue with EWS access on a grommunio/gromox server. The webmail was working, but Apple Mail on macOS could no longer conn...

WalterH

Duese6 *** config key "istore_standalone" has no default and was not set either; yielding 0

Then, set the following parameter: /etc/gromox/gromox.cfg:istore_standalone=0. The message will disappear.

svenology

using the update system function it seems I can't get beyond 3.7..266
which is what I assume was what my update from last Tuesday yielded that wrecked everything.
While things run the same on the phone, that update from last Tuesday tanked performance on Outlook for Mac.
Every machine is pegged at 300% Outlook CPU use the entire time... sending messages takes minutes... receiving new messages 10-15 minutes...
Long story short, things are clearly really messed up.
How is it a week now and still no fix!? For years I have had a perfectly stable and great system... now it's barely usable...

and for a luddite... how would I get the .345 or a newer version when I am on community edition. Shouldn't the update system feature grab that!?
I had hoped that waiting a week would be long enough for a fix to be automatically propagating through update...

HELP!!!!

Mister2

svenology You need to install the development version of gromox mentioned above about 5 days ago by WalterH, and elsewhere in the forum under other threads that also cover this issue.

Look up https://community.grommunio.com/d/2710-outlookprobleme-nach-update-25052026/53

then follow @Huser_IT's and @WalterH posts from this morning at the end of that ticket to do the install of the development version of Gromox you need.

You should find things a lot better after this.

Make sure you download the correct version of the file for the version of OpenSuse you are using (check download.grommunio.com/devel and folow the links for the .345 version of gromox.

Duese6

svenology

I downloaded it manually from here (e.g. for Leap 16):
https://download.grommunio.com/devel/openSUSE_Leap_16.0/

For example:
gromox-3.7.345.xd02abaf-lp160.37.1.x86_64.rpm

Then I copied the RPM to the target machine via WinSCP (e.g. directly into /root)
and installed it with:

rpm -Uvh --oldpackage --nosignature /root/gromox-3.7.345.xd02abaf-lp160.37.1.x86_64.rpm

One thing to keep in mind:
since 3.7.345 is numerically higher than, for example, 3.7.266, the normal update path will not automatically switch you back later.

So if you want to go back to the regular version afterwards, you also have to install the lower version manually via rpm.

WalterH

Duese6 --oldpackage --nosignature

this two parameters ar not needed, you update to a higher version.

svenology

realistically... how long will it take until a proper fix will be published on proper stable update??
development version is all nice and dandy... but we should be able to get this straightened out any moment now and in proper/standard update install...
ESPECIALLY when people are still claiming even the development version does not work properly...

WalterH

svenology how long will it take until a proper fix will

You have to ask the developers.

PiotrPan

Huser-IT

I tried similar changes and play arounds, as it all startet with exceeded connections. Just increasing felt like a hammer, so warning was gone, but outlook (evelolution via EWS as well) stuck like all others reported.

Logs indicate nothing. Just increasing other settings like php-fpm are of no help either.

Reagrding HW capactiy, VM with 4 CPUs and 8GB RAM with 5 users. 3,5GB free mem so shouild be fine.
OOM Killer did not show up....

I do kind of autoupdate, so version is recent but that does not change the sitation. Assumes it could be nine mail on my mobile but that was more correlation than causlity.

Since its my private box, I can likve with daily restart, nontheless there is somewhere obviously a server side bug. so wating for things to change, as logs do not indicate something helpful, since increasing connections.

Huser-IT

PiotrPan

That sounds very similar to what we experienced.

Increasing connection limits, tweaking php-fpm settings and other workarounds did not solve the issue in our environment either. The logs were mostly inconspicuous as well.

We were seeing repeated Outlook password prompts after some time and the only temporary workaround was to restart gromox-http.

A week ago, we installed the developer-recommended build gromox-3.7.345.xd02abaf together with the accompanying recommendations (worker_processes auto; and restarting nginx).

Since then, the system has been rock solid. This is actually the first week in a long time where gromox-http has not required a single restart.

For us, this version solved the issue completely so far.

For reference, our environment is around 50 mailboxes and heavily Outlook-based. So it is not a huge setup, but also not just a tiny test instance.

I have documented the exact steps we performed here:

https://community.grommunio.com/d/2710-outlookprobleme-nach-update-25052026/52

Maybe this helps others facing the same symptoms.

WalterH

Huser-IT We were seeing repeated Outlook password prompts after some time and the only temporary workaround was to restart gromox-http.

I also tried to restart gromox-http, unfortunately restarting gromox-http did not solved this problem for me. Which settings do you have in /etc/gromox/gromox.cfg and /etc/gromox/http.cfg? Can you please post both files, but mask sensitive information.

Huser-IT

WalterH

Thanks for your feedback.

Here are the relevant settings from my configuration files. Sensitive values are masked.

/etc/gromox/gromox.cfg

http_remote_host_hdr=X-Real-IP
http_listen = [::]:10080
http_listen_tls = [::]:10443
imap_listen_tls = [::]:993
pop3_listen_tls = [::]:995
lda_listen = [::1]:24
exmdb_listen = [::]:5000
istore_standalone=0
x500_org_name = <ORG>

/etc/gromox/http.cfg

#listen_port=10080
http_support_ssl=true
#listen_ssl_port=10443
host_id=<FQDN>
http_certificate_path=/etc/grommunio-common/ssl/server-bundle.pem
http_private_key_path=/etc/grommunio-common/ssl/server.key
default_domain=<MYDOMAIN.CH>
context_num=1800
context_average_mem=1024
http_thread_charge_num=40
http_thread_init_num=10
http_log_level=6

Duese6

That matches my experience as well.

Restarting gromox-http or rebooting the server behaved differently across customers, but overall it was never a reliable solution.

In my environment, none of the regular repository versions after 3.7.130 have been consistently usable so far.

The only version from the normal update path that has been stable for me is 3.7.130.

The only newer versions that currently work in my environment are 3.7.345 and 3.7.355, but both of those are devel builds.

WalterH

Today a new Devel. version 3.7.361 was released, can you test this version?

Duese6

WalterH

I have been testing 3.7.361 from Thursday until today.

In my environment, I cannot notice any improvement or behavioral difference compared to 3.7.345 or 3.7.355. Apple Mail is still very laggy.

As suspected, the changes included in this build seem to affect only the IMAP part, so they do not appear to have an impact on the Apple Mail / EWS issue I am seeing

PiotrPan

while not being on the dev build as restart is fine for my personal setup, at least nginx does not seem to be the culprit as tcpdump obviously indicates positive packet flow between client and frontend server.

Sniffing on port 10080 (instead of 10443 after changing prox_pass to http) show request header and ntml auth, but no meaningful response by gromox-http, though at least there are packets flowing rather than a rst. So somehow gromox-http struggles dealing with the SOAP request by the client (in that test case Evolution with EWS)

WalterH

Huser-IT Thank you.
I have one very small mailbox with this problem, I changed these parameters:

/etc/gromox/gromox.cfg

x500_org_name = <ORG>
http_remote_host_hdr=X-Real-IP
# imap_listen = [::]:143
# pop3_listen = [::]:110

/etc/gromox/http.cfg

context_num=1800
context_average_mem=1024K
# please note we need a "K" after 1024!!!
http_thread_charge_num=40
http_thread_init_num=10

http_log_level=6
http_debug=2

Restarted gromox-http and gromox-zcore and now Outlook connects again.
I use the devel. gromox package: gromox-3.7.361

Edit: I guess the changes in /etc/gromox/http.cfg aren't relevant. Outlook connects just fine without these parameters.

Edit: context_average_mem=1024K

Edit: I think this problem is primarily related to the x500_org_name, which appears in 7 configuration files, verify with:

grep -r "^x500" /etc/gromox/*
/etc/gromox/exchange_emsmdb.cfg:x500_org_name=i6XXXX2eb
/etc/gromox/exchange_nsp.cfg:x500_org_name=i6XXXX2eb
/etc/gromox/exmdb_local.cfg:x500_org_name=i6XXXX2eb
/etc/gromox/exmdb_provider.cfg:x500_org_name=i6XXXX2eb
/etc/gromox/gromox.cfg:x500_org_name=i6XXXX2eb
/etc/gromox/midb.cfg:x500_org_name=i6XXXX2eb
/etc/gromox/zcore.cfg:x500_org_name=i6XXXX2eb

The entry x500_org_name must be found in 7 configuration files:
grep -r "^x500" /etc/gromox/* | wc -l

If that don't match, adjust the entries (same value), restart the grommunio services, and test again.
systemctl restart gromox-http gromox-zcore gromox-midb gromox-imap gromox-pop3 nginx php-fpm

If this helps, please let us know here in this thread.

crpb

WalterH context_average_mem=1024

i wondered about this a couple times as the documentation says e.g.

context_average_mem

    Default: 256K

https://docs.grommunio.com/man/http.8gx.html#configuration-directives-http-cfg

Or is the K(ilo) not really needed or will it actually make 1024bit out of you setting?
🙈

WalterH

crpb I guess the "k" is not needed, The unit for this parameter is k. That's my understanding.

crpb

WalterH The unit for this parameter is k. That's my understanding.

we probably need jan to update the manpage so it would be obvious 😛

but it's just too warm right now to open up issues.....

WalterH

WalterH To clarify, I opened Ticket #815491. I will follow up with an answer from Support.

WalterH

WalterH The answer from support:

Hab Jan gefragt weil ich auch keine Info dazu finden konnte.
Antwort: "ohne Suffix keine Multiplikation"
Also bitte immer die gewüschte Größeneinheit verweden.

That means, we set an incorrect value for a long time. Correct is: context_average_mem=1024K

« Previous Page Next Page »