Linux SESSION reset constantly

It sounds like the HTTP cookies are not being set or returned.  Is this on the internet where we can access it with a URL?

If you installed new versions without using the Ubuntu Package Manager, you may find that the paths aren't the same as the standard Ubuntu versions.  You also may find that the permissions weren't set the same either.

Note also that there are two versions of 'php.ini' in stock Ubuntu.  One is used by the command line PHP and another is used by PHP running in Apache.  Unless your new version of PHP replaced both of those, you may not be using the correct one.

Some of the background of what @gr8gonzo wrote:
https://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_11909-PHP-Sessions-Simpler-Than-You-May-Think.html

Hello all,

thanx for responses!

No matter what method, domain, session save path or browser I use, SESSIONS are always re-created for every page refresh. PHP.INI location does not play role, except maybe some settings within it.

I have installed everything with Ubuntu's APT package maneger, except mod_pagespeed, which I removed by simply disabling it within loaded modules.

So again:
I appreciate very much your efforts, but please, do not look for mistakes on USER side. The issue is definitelly on server. I can see the /tmp folder on server getting filled up by new session files with each page refresh, so there's no issue with permissions, PHP.INI location and such.
Maybe something related to REFERRER, or REFERRER's IP or something like that. PHP session handler is not able to associate the current visitor with existing session - that's the problem.

Thank you all!

Back to the original question: It sounds like the HTTP cookies are not being set or returned.  Is this on the internet where we can access it with a URL?

The MOST COMMON mistake I've ever seen (and also done myself) is to discard possibilities. I've told people that an issue is not X and gone down the rabbit hole for days only to find out that it actually -was- X and I had prematurely ruled it out. That said, I know you said there are no issues with permissions, php.ini, and the user, but take it from a guy who helps developers troubleshoot problems on a daily basis - don't assume you're right about those things.

1. Don't discard what Dave is saying - the php.ini file will dictate any session-related configuration, and if PHP is using the wrong php.ini file, then you might end up with unexpected configuration settings. Try creating a phpinfo page (just put <?php phpinfo(); ?> into an empty PHP file and view it in your browser) and post the results here. It will tell you which php.ini file it is currently using and may give some information about your session setup.

2. Keep in mind that if you're using the package manager, then chances are that you're running mod_php, which plugs into Apache. This means that PHP runs as the Apache user and group, and it also means that any changes to the PHP configuration are only loaded when Apache is restarted (which you can do gracefully).

3. Make sure you are testing this problem using the script that I provided in my first comment. If you are testing it within an existing application, then there could be code-related problems that complicate the issue.

4. Check to see if the session files are EVER cleaned up. Sessions configured with an improper lifetime could basically end up getting created and never re-used. If you do use an existing php.ini file, try renaming it and restarting Apache to force PHP to use some default configuration. This can help rule out configuration issues with the php.ini file, but you'll need to use the phpinfo script to make sure that a php.ini file isn't being loaded.

5. It only takes a minute to download and run Fiddler and run a test to make sure that proper communication is happening. It will let you see the cookie settings being sent to the browser and what the browser is sending back. Fiddler is an EXTREMELY useful tool and it's free, so do yourself a favor and run a quick test with it. Preferably save the sessions archive and post the results here, too.

6. The referrer has nothing to do with session handling, unless there is code to change that. Again, use my test script for testing, and make sure you don't have any .htaccess files that change the behavior.

Oh, sorry, I forgot:
YES, of course it is publicaly available. Over 100 domains are affected.

I was just preparing you a link to one customer's site to test...but my test script showed, that this other domain WORKS AS IT SHOULD!

I am now testing from domain to domain to find a pattern...

Hmmm... that's weird.
See these two examples - both pages on the same server, same test script, also PHPINFO seems the same to me:
site 1 - NOT working
site 2 - WORKING

What I noticed is that NON working site adds parameter CSRF_TOKEN to url when clicking on "refresh" link on page, while working site does not.

Hi Dave,

thanx for your input.
Yes, I know that SESSIONS get recreated with every refresh. That's the main problem.

I have tried settings that you recommended, so I set this to empty string instead of "0":
session.referer_check =
But that did not change anything :(

As I examined the issue, it seems related to mod_security.
See PHPINFO pages of above links and scroll to the bottom. The WORKING page has a lot of mod_security stuff there, while the NON-working page does not.

I do not know why is mod_security in charge with one web site, while it is not kicking-in with other.

Did you restart Apache?  Changes in 'php.ini' do not take effect until you do.

Hi Dave,

of course I did restart :)

Still examining the symptom, why one web page employs all the rules of mod_security, while other does not.

So far I got to blind spot:
- session files do get created in both web sites in /tmp directory,
- directory permissions are 777
- session file permissions are 600
- session file CONTAINS data in both sites
- BUT in problematic web sites session file cannot be read by PHP script!

I checked and compared every possible detail, but could not find any differences. Permissions are the same on both sites (except user/group are different, because environment is chrooted). The OWNER of web site directory is memeber only of "sshusers" group.
Apache VHOST files are exactly the same.
PHP is exactly the same version, same method (Fast-CGI).

BUT still the question is why PHPINFO at the very bottom shows different details for each site.

Whoa - hold up! FastCGI? I thought you said you had installed PHP via apt (Ubuntu package manager) or did I misunderstand that? Last time I checked, the packages installed the mod_php, not php-fpm / FastCGI.

FastCGI definitely has different permissions setups, since you're dealing with a separate, dedicated PHP process. Can you give us more details on the configuration and steps you used to upgrade?

Hi,

I cannot provide exact steps of upgrade process, because it was done 1 month ago, then for 14 days we though everything is OK and backups become obsolete. then there was a problem on Magento web sites, which we thought it was due to Mysql 5.1 to 5.5 upgrade, and we fixed it with Magento fix. Then there was a Joomla problem, again, we fixed it, as it was reported only on 1 web site.
Another week later we begun receiving a lot of complaints from Joomla customers, saying they cannot login to backend anymore. So a lot of mess.

Approximate UPGRADE process:
- upgraded MySQL 5.1 to Percona 5.5
- updated PHP from 5.3.x to latest 5.3.x
- added memcache and memcached
- added mod_pagespeed
- (all of above via APT-GET)
- then I tried to complie PHP-FPM 5.4.x as a second PHP for my clients, but could not integrate it into Control Panel. Actually, in WebHosting Control Panel (ISPConfig) I added PHP-FPM with success, but web sites with that option selected did not run PHP-FPM, but previous version of PHP via FastCGI 5.3.x

...then problems begun, as I said, and I removed most or actually ALL of accelerators (memcache, memcached, mod_pagespeed, mod-security) and also:
- updated all packages on server
- upgraded MySQL from 5.5 to 5.6 version, latest

It's hard to experiment, because it is PRODUCTION, web hosting server.

Now the issue is down to these facts:
- 100% web pages are working
- among those, 70% of Joomla sites also enable LOGIN, while 30% of Joomla instalations do NOT allow login due to lack of SESSION. IT does not matter which version of Joomla it is. Affected are all versions from 1.5 to latest 3.x.

Enhanced scripts from GOOD and BAD web sites:
Good, working, session OK
Bad, NON-working, session NOT usable

If I copy script (or whole Jooomla installation) from one site to another, it will behave according to the domain. Working script will become non-working, if I copy it to bad domain.

Oh, my....
How could I (and the whole bunch of experts and my friends) overlook the obvious:

SESSION PARAMETERS from testing web site:
Array ( [lifetime] => 0 [path] => / [domain] => [secure] => 1 [httponly] => )

It was just wrong setting in PHP.INI:

session.cookie_secure = On

Select allOpen in new window

Should be Off.

I have actually found final solution myself, but you helped me with testing script, which made me think. At least but not last, your efforts are worth rewarding, so thank you.

Glad you found it, thanks for the points.