Roundcube creates a new MySQL session on every health check

[imc67]

Third Bug report: Roundcube also creates a new MySQL session on every health check

The same issue we found with Matomo also affects Roundcube. The Cloudron health checker calls GET / every 10 seconds, which causes Roundcube to create a new unauthenticated session in MySQL each time.

Decoded session data from the latest entries:

temp|b:1;
language|s:5:"en_US";
task|s:5:"login";
skin_config|a:7:{...}

This is a pure unauthenticated login page session — no user involved, just the health checker hitting the front page.

Measured growth rate: exactly 6 new sessions per minute per Roundcube instance (= 1 per 10 seconds = health check interval). With 5 Roundcube instances on this server that is 30 new sessions per minute, 43,200 per day.

Suggested fix: Change the health check endpoint from GET / to a static asset that does not trigger PHP session creation, for example:

• A static file like /favicon.ico or /robots.txt
• Or Roundcube's own /index.php/api if available

For reference, WordPress handles this cleanly: GET /wp-includes/version.php returns HTTP 200 with empty output (Wordfence hides the version) without touching the database or creating any session.

It would be great if Cloudron could define a session-free health check endpoint per app type, similar to how it is done for WordPress.

[nebulon]

So the observation is correct as such that each healthcheck call is also creating a session in the database. Given the lack of a real healthcheck route in roundcube itself https://github.com/roundcube/roundcubemail/issues/8372 this is actually not a bad thing to test the app for real by also testing db access here. Querying some static assets isn't really what we want to check for in apps.

Now there are two things, one is that roundcube has a session garbage collector at https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/session/db.php#L199 which appears to be called just fine in all (many years old) instances I have access to. So the sessions will accumulate but then get purged, which is what we actually expect. Can you check how many session records your instances actually have in the database?

[joseph]

From my 5 year old roundcube install:

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|      125 |
+----------+
1 row in set (0.00 sec)

[imc67]

[nebulon]

Do you have any custom configs on that app? Like maybe increased session lifetime or so?
We are no experts on roundcube internals to know what may or may not work here, especially since we cannot reproduce it. So any extra info helps.

[imc67]

Customcofing.php is “empty” and php.ini also

[nebulon]

Digging around the roundcube code, I found that the session garbage collector is called at https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/rcube_session.php#L226 only, however as mentioned this is all very roundcube internal, so I guess one try is to see if the sessions get purged if you restart the app and maybe only then? Though but even if this is the case, I can't see anywhere in roundcube to change this behavior, so there might not be much to be done from a packaging perspective then