adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

Sessions do not get deleted after expiration #477

New Issue
Closed
opened 2026-10-05 00:00:26 +02:00 by adam · 3 comments
adam commented 2026-10-05 00:00:26 +02:00
Owner
Copy link
Copy source

As title says, sessions just keep growing in the database. It has to be deleted manually, or GC has to be triggered by logging in and out.

MariaDB [db]> select expiration from xx_sessions limit 10;
+---------------------+
| expiration          |
+---------------------+
| 2016-07-17 02:06:19 |
| 2016-07-17 02:28:21 |
| 2016-07-17 01:23:06 |
| 2016-07-17 02:05:04 |
| 2016-07-17 02:02:04 |
| 2016-07-17 01:47:05 |
| 2016-07-17 01:53:04 |
| 2016-07-17 02:20:05 |
| 2016-07-17 02:14:06 |
| 2016-07-17 01:41:11 |
+---------------------+
10 rows in set (0.00 sec)

MariaDB [db]> select count(*) as t from xx_sessions;
+-------+
| t     |
+-------+
| 21915 |
+-------+
1 row in set (0.00 sec)

include/functions_sessions.inc.php handles GC:

function pwg_session_gc()
{
  global $conf;

  $query = '
DELETE
  FROM '.SESSIONS_TABLE.'
  WHERE '.pwg_db_date_to_ts('NOW()').' - '.pwg_db_date_to_ts('expiration').' > '
  .$conf['session_length'].'
;';
  pwg_query($query);
  return true;
}

There is no local override of $conf['session_length'] = 3600;

GC is called from pwg_login when actually logging in. So if a single user stays logged in forever, there is no expiration.

In practical terms, this means that a small and rarely visited gallery will have a sessions table of 50 MB within two weeks. For more active galleries, this will wreak havoc where resources are limited, for example in shared environments.

This is new behavior for Piwigo, it was not like this before. GC should be done periodically by route of some common user interaction.

As title says, sessions just keep growing in the database. It has to be deleted manually, or GC has to be triggered by logging in and out. ``` MariaDB [db]> select expiration from xx_sessions limit 10; +---------------------+ | expiration | +---------------------+ | 2016-07-17 02:06:19 | | 2016-07-17 02:28:21 | | 2016-07-17 01:23:06 | | 2016-07-17 02:05:04 | | 2016-07-17 02:02:04 | | 2016-07-17 01:47:05 | | 2016-07-17 01:53:04 | | 2016-07-17 02:20:05 | | 2016-07-17 02:14:06 | | 2016-07-17 01:41:11 | +---------------------+ 10 rows in set (0.00 sec) MariaDB [db]> select count(*) as t from xx_sessions; +-------+ | t | +-------+ | 21915 | +-------+ 1 row in set (0.00 sec) ``` include/functions_sessions.inc.php handles GC: ``` php function pwg_session_gc() { global $conf; $query = ' DELETE FROM '.SESSIONS_TABLE.' WHERE '.pwg_db_date_to_ts('NOW()').' - '.pwg_db_date_to_ts('expiration').' > ' .$conf['session_length'].' ;'; pwg_query($query); return true; } ``` There is no local override of `$conf['session_length'] = 3600;` GC is called from `pwg_login` when actually logging in. So if a single user stays logged in forever, there is no expiration. In practical terms, this means that a small and rarely visited gallery will have a sessions table of 50 MB within two weeks. For more active galleries, this will wreak havoc where resources are limited, for example in shared environments. This is new behavior for Piwigo, it was not like this before. GC should be done periodically by route of some common user interaction. <!-- github-sync-id:168502955 -->
adam closed this issue 2026-10-05 00:00:26 +02:00
adam commented 2026-10-05 00:00:27 +02:00
Author
Owner
Copy link
Copy source

Can you look at your php config? The session.gc_probability and session.gc_divisor params

Can you look at your php config? The session.gc_probability and session.gc_divisor params <!-- github-comment-id:236550026 -->
adam commented 2026-10-05 00:00:28 +02:00
Author
Owner
Copy link
Copy source

They default to 0 and 1400 on Ubuntu systems. GC is instead done via script /usr/lib/php/sessionclean

They default to 0 and 1400 on Ubuntu systems. GC is instead done via script /usr/lib/php/sessionclean <!-- github-comment-id:236573766 -->
adam commented 2026-10-05 00:00:29 +02:00
Author
Owner
Copy link
Copy source

So @zuiguniang confirms that on Debian-like systems, the garbage collector is never triggered. We only rely on the pwg_login execution to purge sessions. I agree it is not perfect and we can't ask all Debian-like users to change their session.gc_probability. But read http://piwigo.org/forum/viewtopic.php?id=23727

Maybe we should include ini_set("session.gc_probability", 1) somewhere.

So @zuiguniang confirms that on Debian-like systems, the garbage collector is never triggered. We only rely on the pwg_login execution to purge sessions. I agree it is not perfect and we can't ask all Debian-like users to change their session.gc_probability. But read http://piwigo.org/forum/viewtopic.php?id=23727 Maybe we should include `ini_set("session.gc_probability", 1)` somewhere. <!-- github-comment-id:238610125 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#477