What is your set up?
Self Hosted - Docker (leantime/leantime:3.7.3), Redis backend (LEAN_USE_REDIS=true).
Describe the issue
I'm trying to confirm the unit of LEAN_SESSION_EXPIRATION and would appreciate guidance, because what I'm observing on my instance doesn't seem to match what the docs say. I may be misreading something — hence this question rather than a bug report.
How I ended up looking at this
My nightly Proxmox Backup Server backup of the LXC running Leantime started failing with:
Error: upload failed: error at "var/lib/docker/overlay2/.../diff/var/www/html/storage/framework/sessions":
exceeded allowed number of file entries (> 1048576)
Leantime had accumulated 1,189,176 session files in storage/framework/sessions/, all roughly 189 bytes each, with the oldest dating back several weeks. This pushed the container over proxmox-backup-client's default 1,048,576-entry cap, breaking off-site backups.
My LEAN_SESSION_EXPIRATION was set to 86400, which the docs describe as seconds (= 24 h). With file-based sessions, I would have expected garbage collection to remove sessions older than ~24 h — but files from over a month ago were still present, suggesting the actual session lifetime was much longer than documented.
I've since switched to Redis-backed sessions to make the problem self-cleaning via TTL, and that's where the unit question became concrete.
What the docs and sample files say
Multiple places describe LEAN_SESSION_EXPIRATION as seconds:
config/sample.env: LEAN_SESSION_EXPIRATION = 28800 # How many seconds after inactivity should we logout? 28800seconds = 8hours- https://docs.leantime.io/installation/configuration:
LEAN_SESSION_EXPIRATION=28800 # Session timeout in seconds (8 hours default)
- The Getting Started guide uses the same
28800 value with the same framing.
What I'm observing in 3.7.3
In my running container, config/session.php contains:
'lifetime' => env('LEAN_SESSION_EXPIRATION', 480), // 8 hours
'expire_on_close' => false,The 480 default with an // 8 hours comment suggests the value is in minutes, since Laravel's session lifetime is treated as minutes by framework convention (480 min = 8 h, whereas 480 s would be 8 min). PR #2823 (which closed #2821) wired the env var through to this config slot.
Empirical observation in Redis
After switching to LEAN_USE_REDIS=true with LEAN_SESSION_EXPIRATION=86400 still set, I checked the TTL on leantime_sessions:* keys:
leantime_sessions:... -> TTL 5183480s
~5,184,000 seconds = 86,400 × 60. The value appears to be interpreted as minutes, not seconds — i.e., 86,400 minutes = 60 days, which matches what Redis reports. After changing to LEAN_SESSION_EXPIRATION=10080 (intending 7 days as minutes) and capping existing TTLs at 604,800 s, new sessions match a 7-day expectation if the value is read as minutes.
If the same minutes-interpretation applies to the file-based session driver, that would also explain why my storage/framework/sessions/ directory grew to over a million files: with 86400 interpreted as minutes (= 60 days) instead of seconds (= 24 h), Laravel's probabilistic GC would remove far fewer files than expected, allowing weeks of accumulation.
Question
Is my interpretation correct that LEAN_SESSION_EXPIRATION is consumed by Laravel's session config as minutes, and the docs/sample comments referring to "seconds" are outdated since #2823 changed how this variable is consumed? Or is there something elsewhere in the code that converts seconds→minutes that I'm missing?
If the docs are indeed describing the wrong unit, I'm happy to open a PR against Leantime/docs and update the sample.env comment — I just want to confirm with a maintainer before doing so, since this affects every user following the documentation verbatim. The documented 28800 would yield ~20-day sessions instead of the intended 8 hours, with knock-on effects on session-file accumulation for users on the file driver.
Thanks for the great project. :)
What is your set up?
Self Hosted - Docker (
leantime/leantime:3.7.3), Redis backend (LEAN_USE_REDIS=true).Describe the issue
I'm trying to confirm the unit of
LEAN_SESSION_EXPIRATIONand would appreciate guidance, because what I'm observing on my instance doesn't seem to match what the docs say. I may be misreading something — hence this question rather than a bug report.How I ended up looking at this
My nightly Proxmox Backup Server backup of the LXC running Leantime started failing with:
Leantime had accumulated 1,189,176 session files in
storage/framework/sessions/, all roughly 189 bytes each, with the oldest dating back several weeks. This pushed the container overproxmox-backup-client's default 1,048,576-entry cap, breaking off-site backups.My
LEAN_SESSION_EXPIRATIONwas set to86400, which the docs describe as seconds (= 24 h). With file-based sessions, I would have expected garbage collection to remove sessions older than ~24 h — but files from over a month ago were still present, suggesting the actual session lifetime was much longer than documented.I've since switched to Redis-backed sessions to make the problem self-cleaning via TTL, and that's where the unit question became concrete.
What the docs and sample files say
Multiple places describe
LEAN_SESSION_EXPIRATIONas seconds:config/sample.env:LEAN_SESSION_EXPIRATION = 28800 # How many seconds after inactivity should we logout? 28800seconds = 8hoursLEAN_SESSION_EXPIRATION=28800 # Session timeout in seconds (8 hours default)28800value with the same framing.What I'm observing in 3.7.3
In my running container,
config/session.phpcontains:The
480default with an// 8 hourscomment suggests the value is in minutes, since Laravel's sessionlifetimeis treated as minutes by framework convention (480 min = 8 h, whereas 480 s would be 8 min). PR #2823 (which closed #2821) wired the env var through to this config slot.Empirical observation in Redis
After switching to
LEAN_USE_REDIS=truewithLEAN_SESSION_EXPIRATION=86400still set, I checked the TTL onleantime_sessions:*keys:~5,184,000 seconds = 86,400 × 60. The value appears to be interpreted as minutes, not seconds — i.e., 86,400 minutes = 60 days, which matches what Redis reports. After changing to
LEAN_SESSION_EXPIRATION=10080(intending 7 days as minutes) and capping existing TTLs at 604,800 s, new sessions match a 7-day expectation if the value is read as minutes.If the same minutes-interpretation applies to the file-based session driver, that would also explain why my
storage/framework/sessions/directory grew to over a million files: with86400interpreted as minutes (= 60 days) instead of seconds (= 24 h), Laravel's probabilistic GC would remove far fewer files than expected, allowing weeks of accumulation.Question
Is my interpretation correct that
LEAN_SESSION_EXPIRATIONis consumed by Laravel's session config as minutes, and the docs/sample comments referring to "seconds" are outdated since #2823 changed how this variable is consumed? Or is there something elsewhere in the code that converts seconds→minutes that I'm missing?If the docs are indeed describing the wrong unit, I'm happy to open a PR against
Leantime/docsand update thesample.envcomment — I just want to confirm with a maintainer before doing so, since this affects every user following the documentation verbatim. The documented28800would yield ~20-day sessions instead of the intended 8 hours, with knock-on effects on session-file accumulation for users on the file driver.Thanks for the great project. :)