CODEWITHSUNDEEP
phpsymfonysessionsymfony-3.4
DrKey
DrKey

Reputation: 3495

PHP - Session object destruction failed

I'm facing a strange problem on Symfony: basically sometimes, without any apparent reason, the user is unable to load web pages until I restart php-fpm or until he changes its PHPSESSID loading a new session. Anyway his session is still working properly after fpm is restarted.

At the same time, I got 2 warnings from PHP:

PHP Warning: session_start(): Session object destruction failed in /home/unix/releases/1/vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php on line 145

PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in /home/unix/releases/1/vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php on line 145

Consider that we are talking about a private website used maximum from 2-3 users concurrently, but it might also happen if just 1 user is navigating on it.

Current setup is

I'm able to reproduce the issue using apache ab calling different URLs concurrently using the same session id. Of course after N requests I got timeout:

Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
apr_pollset_poll: The timeout specified has expired (70007)
Total of 872 requests completed

Now I'm trying to check php configuration but actually is quite "normal" without special settings so I don't know what should I try or check. Any thoughts?

Upvotes: 3

Views: 1697

Answers (1)

DrKey
DrKey

Reputation: 3495

The problem

Finally I was able to find the problem. Basically it comes from Symfony itself since by default seems that it also implements kind of garbage collection logic in Symfony/Component/HttpFoundation/Session/Storage/Handler/StrictSessionHandler.php

public function gc($maxlifetime)
{
    return $this->handler->gc($maxlifetime);
}

This wouldn't be a problem if /var/lib/php/sessions/ directory belongs to the same user defined in php.ini or if it has read permissions, but by default that directory belongs to root user and is not readable (so files cannot be listed). This causes an exception when Symfony tries to call the garbage collector on current session handler.

The solution

There are two solutions: setting

session:
    gc_probability: ~

in Symfony config.yml or adding read permission to PHP sessions directory (or eventually change relative user using the same defined in php.ini). Hope it might help someone.

Upvotes: 3

Related Questions