@souverain
A short update from our side:
We are experiencing what appears to be the same issue after the Gromox update v3.7.226.ab0dc23 from 25 May 2026.
Observed behaviour:
- Outlook (Classic) can no longer connect after some time.
- Existing Outlook sessions may continue to work until Outlook is restarted.
- Webmail and ActiveSync continue to work normally.
- Restarting
gromox-http immediately restores Outlook connectivity.
- In some cases, even restarting
gromox-http takes an unusually long time and appears to hang temporarily.
For troubleshooting, we tested the following changes:
/etc/gromox/http.cfg
context_num=1800
context_average_mem=1024
http_thread_charge_num=40
http_thread_init_num=10
; Increased log level for troubleshooting purposes only. Should be removed or set back to "3" after troubleshooting.
http_log_level=6
/etc/php8/fpm/php-fpm.d/pool-grommunio-web.conf
; commented out the original dynamic process manager settings:
;pm = dynamic
;pm.start_servers = 8
;pm.min_spare_servers = 8
;pm.max_spare_servers = 16
; enabled ondemand process management:
pm = ondemand
pm.process_idle_timeout = 10s
pm.max_requests = 100
/etc/nginx/nginx.conf
→ Set value to 50% of the available CPU cores
worker_processes 4;
Important: these changes did not resolve the issue. However, they seem to have reduced the frequency of the outages in our environment. This may simply be a coincidence, so further testing is required.
We have also verified that the issue occurs when accessing grommunio directly without a WAF or reverse proxy in front of it.
Support has informed us that multiple customers have reported similar behaviour and that development is already investigating the problem.
Edit: The grommunio support provided the following information:
The optimal settings under /etc/gromox/* depend heavily on the specific environment, workload and requirements. The default values are chosen to provide reasonable performance even on smaller systems.
Unfortunately, there is currently no official sizing guide or tuning recommendation available. However, Gromox logs warnings in the journal whenever a particular limit is reached. This allows administrators to gradually tune their systems based on actual usage patterns.
As long as sufficient system resources are available, it is generally safe to increase these values step by step (for example by doubling them) until the corresponding journal warnings no longer appear.
For worker_processes in nginx.conf, the recommendation is to use approximately 50% of the available CPU cores.
