@aureq opened this Issue on January 27th 2019


Matomo changes PHP default behavior by altering the location (path) where the PHP sessions are stored. The location is in INSTALL_DIR/tmp/sessions/.

The main problem is PHP sessions aren't purged/deleted automatically, leaving a lot of sess_* behind and consuming unnecessary disk space. Debian tried to address the issue via /etc/cron.d/php5 but since the default location has changed, the session files can't be located by the script and thus can't be deleted.

Looking into the code, this appears to be around this function: https://github.com/matomo-org/matomo/blob/3.x-dev/core/Session.php#L161

As a possible solution, create a new setting entry allowing for the path to be changed by the administrator. If the value is present, then matomo uses the said value. If not, Matomo doesn't attempt to change the session path and let the system deal with it. https://github.com/matomo-org/matomo/blob/3.x-dev/core/Session.php#L97

A clear advantage to this is also to allow session files to be saved in memcache/redis natively. Also this would allow systems running Debian/Ubuntu to purge outdated session files as part of the OS daily routine.

@tsteur commented on January 27th 2019 Member

Since Matomo 3.8 it should use sessions in the DB. This should no longer be an issue?

@aureq commented on January 27th 2019

I think it's still is an issue. For example, leaving the system deal with session gives a great opportunity to leverage memcached/redis as a session store and that's going to be faster than a DB (which may receive additional load from other activities).
Ideally, administrators should have the options of:

  1. Let the system determine where to store the session (PHP default behavior)
  2. Allow Matomo to store sessions in file at a specified location
  3. Allow Matomo to store sessions in its own database

I also think that in both 2 and 3, Matomo should clean up the files left behind. In the case of 2, this is not currently the case as one of my systems ran out of inodes this morning.

@tsteur commented on January 28th 2019 Member

Performance wise you shouldn't experience much of a performance experience between Redis / DB and they shouldn't add much to your DB load as it's a tiny table and fast queries etc. For sure if you want to use redis or so you (by setting the session handler to an empty string) and configuring PHP. You can also configure PHP to use file sessions and use any directory (Matomo should no longer set a directory if you configure file sessions through PHP and configure an empty session handler in the Matomo config), it's just Matomo itself won't use the file sessions anymore.

@aureq commented on January 28th 2019

Ok, this is great then. Could it be possible to get this documented in the global.ini.php please? The initial comment didn't make it clear it was OK to leave the setting with no value.


; by default, Matomo uses PHP's built-in file-based session save handler with lock files.
; For clusters, use dbtable.
session_save_handler = files


; By default, Matomo uses PHP's built-in file-based session save handler with lock files. 
; If 'session_save_handler' is set to 'files' then sessions are handled by PHP and saved in 'tmp/sessions/' folder controlled by Matomo.
; For clusters, use 'dbtable' to store session states inside Matomo's database
; If the value is empty, then sessions are stored according to the system 'php.ini' setting. 
session_save_handler = files

Beyond the change proposed above, Matomo should consider cleaning up session files when session_save_handler = files since it's not the OS default setting. The code should also honor session.gc_maxlifetime as part of php.ini.


@tsteur commented on January 28th 2019 Member

@aureq we've already updated it just recently to

; Matomo uses PHP's dbtable for session.
; If you prefer configuring sessions through the php.ini directly, you may unset this value to an empty string
session_save_handler = dbtable

maybe that already helps?

Powered by GitHub Issue Mirror