Summary
After upgrading SOGo and SOPE from version 5.12.9 to 5.12.10, idle MariaDB connections opened by sogod progressively accumulate.
The connection count does not appear to return to a small stable pool. It can eventually reach MariaDB's max_connections limit, after which SOGo starts returning HTTP 501 responses for multiple CalDAV and CardDAV requests and becomes unavailable.
Using the same configuration, database, workload and number of workers, downgrading SOGo and SOPE to 5.12.9 restores the previous behaviour: unused SQL connections are released and the number of connections remains stable.
All customer names, domains, addresses, credentials and public IP addresses have been replaced or omitted from this report.
Environment
- Affected SOGo version: 5.12.10
- Affected SOPE version: 5.12.10
- Comparison SOGo version: 5.12.9
- Comparison SOPE version: 5.12.9
- Installation method: source build from the corresponding official Git tags
- Container base image: Debian stable-slim
- Database: MariaDB 12.3.3
- Reverse proxy: nginx
- Deployment: Docker Compose
- Number of SOGo workers: 10
- Number of mail accounts: approximately 10
- Client protocols: mainly CalDAV and CardDAV
- SOGo and MariaDB run in separate containers on the same Docker network
Both versions were tested with the same SOGo configuration, MariaDB configuration, worker count and normal client workload.
Relevant SOGo configuration
Sensitive values have been replaced with placeholders.
WOWorkersCount = 10;
WOWatchDogRequestTimeout = 10;
WOListenQueueSize = 50;
SOGoProfileURL =
"mysql://sogo:<REDACTED>@mariadb:3306/sogo/sogo_user_profile";
OCSFolderInfoURL =
"mysql://sogo:<REDACTED>@mariadb:3306/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"mysql://sogo:<REDACTED>@mariadb:3306/sogo/sogo_sessions_folder";
OCSAdminURL =
"mysql://sogo:<REDACTED>@mariadb:3306/sogo/sogo_admin";
An additional SQL user source reads account information from a view in another database. Its database name, table/view name, domain and credentials have been omitted.
Relevant MariaDB configuration
The following MariaDB settings were identical during both tests:
max_connections = 300
wait_timeout = 3600
interactive_timeout = 3600
Symptoms with SOGo/SOPE 5.12.10
With version 5.12.10, idle MariaDB connections belonging to the sogo database user progressively increased.
The connections appeared in information_schema.PROCESSLIST as:
USER DB COMMAND
sogo sogo Sleep
Example measurements:
Time Idle SOGo connections Longest current idle time
15:00 15 535 s
15:01 16 595 s
15:02 17 655 s
15:03 18 715 s
15:05 20 835 s
15:08 23 1016 s
15:17 33 1606 s
15:18 34 1666 s
15:20 36 1786 s
15:23 38 1966 s
15:27 42 2206 s
15:29 44 2327 s
15:30 46 2387 s
15:32 47 2493 s
15:39 53 2927 s
15:40 55 2987 s
15:42 56 3108 s
15:44 58 3228 s
15:45 58 3288 s
The number therefore increased from 15 to 58 idle connections in approximately 45 minutes.
During the measurements, MariaDB showed very little active work:
Threads_running = 1
Connection_errors_max_connections = 0
Max_used_connections = 69
This suggests that the connections were not caused by blocked or long-running queries. Most connections were sleeping.
Production impact
During an earlier occurrence, the progressive accumulation eventually reached MariaDB's connection limit.
MariaDB then logged errors similar to:
Aborted connection 0 to db: 'unconnected'
user: 'unauthenticated'
host: 'connecting host'
(Too many connections)
At the same time:
- SOGo became inaccessible;
- CalDAV and CardDAV synchronizations failed;
- SOGo returned HTTP 501 for multiple users;
- calendar, calendar inbox and address-book DAV resources were affected;
- unrelated mail components using the same MariaDB server also experienced connection failures.
The container health check could still report SOGo as healthy because a simple unauthenticated HTTP request continued to receive a response, while authenticated DAV operations failed because no SQL connection was available.
Restarting SOGo or MariaDB temporarily restored service, but the connections began accumulating again with version 5.12.10.
Comparison with SOGo/SOPE 5.12.9
SOGo and SOPE were rebuilt from the 5.12.9 tags.
Only the SOGo container was recreated. MariaDB was not restarted, and its configuration was not changed.
The SOGo container reported:
SOGO_VERSION=5.12.9
RestartCount=0
The process tree contained:
1 sogod master
10 sogod workers
All workers had the same parent process and the same start time. No container or worker restart occurred during the following measurements.
Results with version 5.12.9:
Time Idle SOGo connections Longest current idle time
15:46 14 33 s
15:47 14 93 s
15:48 14 153 s
15:49 14 213 s
15:50 14 273 s
15:51 6 323 s
15:52 5 383 s
15:53 6 443 s
15:54 5 503 s
15:55 5 563 s
15:56 6 623 s
15:57 6 683 s
15:58 6 743 s
15:59 6 803 s
16:00 5 863 s
16:01 5 923 s
16:02 6 984 s
16:03 6 1044 s
16:04 6 1104 s
16:05 5 1164 s
16:06 6 1224 s
16:07 5 1284 s
16:08 9 1344 s
16:09 9 1404 s
16:10 9 1464 s
16:11 8 1524 s
16:12 8 1584 s
16:13 7 1644 s
16:14 8 1704 s
16:15 8 1765 s
16:16 7 1825 s
16:17 7 1885 s
16:18 6 1922 s
After an initial reduction from 14 connections, the SOGo connection count remained between approximately five and nine connections for more than 30 minutes under normal activity.
At the end of this observation:
SOGo idle connections = 6
Total application connections = 11
Threads_running = 1
Connection_errors_max_connections = 0
SOGo container restarts = 0
Aborted_clients did not increase during the 5.12.9 observation.
The increase previously seen in Aborted_clients occurred when the 5.12.10 container was deliberately stopped and recreated as 5.12.9. It did not continue after 5.12.9 was started.
Interpretation of MariaDB TIME
For a connection in the Sleep state, the TIME column represents its current idle duration, not its complete lifetime.
Some individual connections remained idle for more than 1,800 seconds with version 5.12.9. This is not itself considered abnormal because the total number of connections remained small and bounded.
The significant difference is the connection-count behaviour:
SOGo/SOPE 5.12.10:
15 to 58 idle connections, with continued growth
SOGo/SOPE 5.12.9:
14 initially, then stable between approximately 5 and 9
The MariaDB wait_timeout was 3600 seconds for both tests.
With 5.12.9, most unused connections were released after approximately five minutes, well before the MariaDB timeout. With 5.12.10, the number continued increasing while older idle connections remained present.
Database monitoring query
The same query was used for both versions:
SELECT
NOW() AS measurement,
COUNT(*) AS connections,
MIN(TIME) AS shortest_idle_time,
MAX(TIME) AS longest_idle_time,
SUM(TIME >= 3300) AS near_timeout,
SUM(TIME >= 3600) AS beyond_timeout
FROM information_schema.PROCESSLIST
WHERE USER = 'sogo'
AND COMMAND = 'Sleep';
Global MariaDB status was monitored using:
SHOW GLOBAL STATUS
WHERE Variable_name IN (
'Threads_connected',
'Threads_running',
'Max_used_connections',
'Connection_errors_max_connections',
'Aborted_clients',
'Aborted_connects'
);
Expected behaviour
SQL connections opened by a fixed number of sogod workers should be reused or released. The total number of connections should remain bounded under a small and stable workload.
Actual behaviour
With SOGo/SOPE 5.12.10, idle SQL connections progressively accumulate. During a previous occurrence, they contributed to exhaustion of MariaDB's connection limit and caused DAV requests to fail.
With SOGo/SOPE 5.12.9, using the same configuration and ten workers, the SQL connection count quickly decreases and remains bounded at approximately five to nine connections.
Steps to reproduce
- Configure SOGo with a MariaDB backend and multiple standard SOGo database URLs.
- Configure ten
sogod workers.
- Start SOGo/SOPE 5.12.10.
- Generate normal CalDAV and CardDAV activity from several user accounts.
- Monitor sleeping connections for the
sogo MariaDB user.
- Observe that the number of idle connections progressively increases.
- Rebuild SOGo and SOPE from the 5.12.9 tags without changing the configuration.
- Recreate only the SOGo container.
- Repeat the same monitoring under normal client activity.
- Observe that the number of idle SOGo connections decreases and remains bounded.
Possible affected component
The issue may be related to SQL channel retention, reuse or cleanup in SOGo/SOPE 5.12.10, possibly in the GCS channel manager or MySQL/MariaDB channel implementation.
Questions
Could you please confirm:
- Whether SQL channel management changed between SOGo/SOPE 5.12.9 and 5.12.10?
- Whether there is a known regression affecting MySQL/MariaDB connection cleanup?
- Whether a new configuration option is required in version 5.12.10?
- Whether additional debug logging can be enabled specifically for GCS or SQL channel allocation and release?
Complete sanitized configuration files, longer monitoring data and debug logs can be provided if required. | 
