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.

imc67

@nebulon said:

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.

my apologies, I was on the road and answered too quickly after checking via filemanager on my phone ... the wrong Roundcube instance ...

On this server I have 5 Roundcube apps (because aliases are not in the app package available) and 3 of them have this issue and indeed all three they do have in common in the custom config:
$config['session_lifetime'] = 600;

Once upon a time in 2022 it was suggested/advised here https://forum.cloudron.io/post/46033 and so I used that ever since.

I deleted the line, restarted the apps, waited a few minutes and the session increase is now 'normal'.

I also restarted MySQL server and it used 2.6 GB of the assigned 8GB and after restarting it starts at 416MB.

This part 3 of the discovered possible issues for high disk I/O is solved.

Let's continue with the possible Matomo issue in https://forum.cloudron.io/topic/14639/cloudron-v9-huge-disk-i-o-is-this-normal-safe-needed/

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

robi

@nebulon if nothing in the code calls it, is there an external script or cron?

imc67