Bug #93878
closedTYPO3 uses flock() directly (hard-wired) for session locking
0%
Description
While the locking API makes it possible to configure and extend the locking with alternatives (e.g. Redis), this is not possible for locking used in the session files.
This uses flock() directly, which may fail on NFS bases storages (see #72074).
It is not possible to override this.
If this is not known, this can be a problem.
My recommendation / workaround is to symlink specific directories to local storage. However, this is currently not documented well and may create problems if you for example symlink the entire directories (including the assets) and use multiple servers.
In addition to this, if flock() fails for the session file, you get a misleading error message:
'Session file not writable. Please check permission on ' . $this->sessionPath . ' and its subdirectories.', 1424355157
Source code¶
typo3/sysext/install/Classes/Service/Session/FileSessionHandler.php:
public function read($id)
{
$sessionFile = $this->getSessionFile($id);
$content = '';
if (file_exists($sessionFile)) {
if ($fd = fopen($sessionFile, 'rb')) {
$lockres = flock($fd, LOCK_SH);
public function write($id, $sessionData)
{
$sessionFile = $this->getSessionFile($id);
$result = false;
$changePermissions = !@is_file($sessionFile);
if ($fd = fopen($sessionFile, 'cb')) {
if (flock($fd, LOCK_EX)) {
Conclusion¶
Any (or all) of the following might be helpful:
use locking API in session as well and not flock() directly
Not possible because used in install tool - should not depend on locking api
- add a check if flock is supported on system to environment check, see also https://review.typo3.org/c/Packages/TYPO3.CMS/+/45154/3/typo3/sysext/core/Classes/Locking/FileLockStrategy.php
- improve documentation
- improve error message
Updated by Sybille Peters over 3 years ago
- Related to Bug #72074: FileLockStrategy fails on NFS folders added
Updated by Benni Mack about 1 year ago
- Related to Bug #101059: Allow install tool sessions without shared file system added
Updated by Sybille Peters 2 months ago
Update : the session files in var/session should not be on NFS anyway, but in local storage (if I understand this correctly). When I wrote the issue, the session files existed in shared storage NFS in my installation (which is no longer the case).
So, currently I am not sure if this is really a problem since obviously I was doing something incorrectly and the problem would not have arisen otherwise.
However it might be helpful to document how to organize files on load-balanced systems / cluster with shared storage.
I am ok, if this issue is closed - perhaps it is sufficient to handle this in #101059
Updated by Garvin Hicking 2 months ago
- Status changed from New to Closed
I agree and would close this in favor of the other ticket, thanks!