session.gc_maxlifetime = 86400

[hcooper]

Users have been complaining about frequently being logged out.

After much experimenting I think it comes down to this value.

The previous default was 24 minutes. I've not investigated further but I suspect a recent upgrade changed that default to something previously higher.

Tested running the sed command by hand.

[BenjaminPelletier]

This seems awfully unlikely to address whatever the root cause of the situation is unless MediaWiki is using PHP sessions to manage login persistence (and if that's the case, why is that the case?). Please see below what ChatGPT had to say. I'm hesitant to change things that aren't likely to be the root cause since that's likely to hide the root cause making it more difficult to resolve later and more likely to cause other problems.

I have an older MediaWiki deployment (recently updated to 1.35) where users have recently started complaining of being logged out after only a short period of time. A collaborator found that apparently increasing the session.gc_maxlifetime PHP setting might improve things. This seems strange to me; could it be that MediaWiki is relying purely on PHP sessions to maintain login state? Or, am I misinterpreting what might be happening?

Great question – let’s clarify how MediaWiki manages login sessions and how session.gc_maxlifetime affects them.

How MediaWiki manages login sessions

1. By default (traditional behavior):

   • MediaWiki stores authentication via login cookies (not PHP sessions) to keep users logged in.
   • These cookies contain login tokens validated against the user and user_token fields in the database.
   • PHP sessions are used for other short-lived state (e.g. some temporary user data, OAuth flows, or preferences editing) but not for general login persistence.

2. However, with certain configurations:

   • If you have extensions or configuration options that enable session-based authentication (e.g. CentralAuth with certain setups, or $wgPHPSessionHandling = true in older configurations), then PHP session lifetime directly affects login duration.
   • MediaWiki’s [SessionManager](https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager) architecture can store session data in PHP sessions or alternative backends (e.g. Memcached, Redis, DB-backed session storage).

3. session.gc_maxlifetime relevance:

   • If MediaWiki is using PHP’s default file-based sessions, then session.gc_maxlifetime controls how long PHP considers a session valid.
   • If gc_maxlifetime is shorter than the cookie expiration, the session might disappear from disk, forcing re-login despite a valid cookie.

4. Possible causes for your users’ problem:

   • Short PHP session lifetime when MediaWiki is configured to store auth sessions in PHP sessions.

   • Cookie misconfiguration, such as:

     • Login cookie expiry set too short (check $wgCookieExpiration).
     • Mismatch between cookie domain/path and site URL.

   • Cache issues, if session data is stored in a shared cache (Memcached or Redis) with short expiry.

5. Action items to diagnose and resolve:

   • Check $wgCookieExpiration in your LocalSettings.php. It defaults to 30 days (2592000 seconds).
   • Check your session.gc_maxlifetime in php.ini or .user.ini. It defaults to 1440 seconds (24 minutes), which is often too short for session-based auth usage.
   • Look at $wgSessionCacheType and $wgSessionHandling (if present) to see if your MediaWiki is using PHP sessions for auth. If not, session.gc_maxlifetime won’t affect login.
   • Confirm your cache backend TTL (if using Memcached/Redis) is sufficiently long for session data.

6. Recommended approach:

   • If you are not intentionally using PHP sessions for login, increasing session.gc_maxlifetime will not fix underlying issues.
   • If you are (e.g. CentralAuth with session-based login), increase it to match or exceed $wgCookieExpiration.
   • Review LocalSettings.php and any extensions affecting auth/session management.

Let me know your $wgCookieExpiration setting, your caching/session configuration (especially any Redis or Memcached setups), and your PHP session backend, and I can provide a tailored recommendation to resolve this efficiently.