Fatal: /var/lib/php/session not existing or not writable

[james88]

Hi,

I am trying to get PHP Link Directory v2 running on my VPS (which is running Plesk to administer domains). The server has a Fedora core.

Upon setting up the database and setting write permissions on the relevant folders I am still hitting an error "Fatal: /var/lib/php/session not existing or not writable" on page {url no longer in service}

For me to make this writable, do I need root access as I don't seem to be able to 'get' to it and change it to writable (I don't have root access on my VPS), whereas I could with the other folders (CHMODing them).

Is there are way to set var/lib/php/session to somewhere else on my server, say in the www directory so that I can CHMOD it there is is it essential (for security or otherwise) for the /var/lib/php/session to exist in that directory?

Please help, I really want to get this going.

Thankyou
James[/b]

[dcb]

In fact it's quite simple to get around this.

At the begining of include/config.php write the following line:
session_save_path("/your/session/path/");

:!: You must include the trailing slash at the end of the path.

[james88]

Thankyou very much - you're a super star, I just added the line you said and all is well!! :wink:

I have a quick question, the session save path now points to a folder /httpdocs/sessionsave and I have CHMOD'd this folder to 777. Is this secure? (This folder is accesible via the web)

Again THANKYOU FOR YOUR HELP! - it seems to be working :D

[dcb]

Well.. it would be a lot better if it wouldn't be accessible over the web.

[james88]

Hi,

If I can get the session directory out of the web accessible directory, will this be OK to be left CHMOD'd as 777. I have a /private directory on my server so I can have a go at putting it there - this is one level below /httpdocs (the web directory).

Thankyou in advance
James
:)

[dcb]

Yes, that would be ok.

[james88]

I now notice that as I use phplinkdirectory, (which seems to be working absolutely fine), in my httpdocs/sessionsave folder there are files appearing which presumably (without sounding stupid) - ARE the saved sessions. Will this folder now just fill up forever with session IDs or will it 'manage' itself?

What is the best way to deal with this, it wouldn't be healthy for it just to fill up indefinately with session IDs as I'd run out of disk space. Should I run chron jobs on it to delete files? Please suggest what I should do.

Thankyou once again for you invaluable help.

James

[dcb]

PHP has a builtin garbage collector that deletes expired session files from time to time. But I'm not 100% sure if it also works after setting a different session save path from code. Different from the one set by php.ini I mean.

The best would be to watch it for a while and see if files pile up.

[Anonymous]

My sessionsave folder seems to be filling up?! - is there any way around this?

Thanks
James

[dcb]

Well... you can try removing the line that changes the default session path from /include/config.php now that the script has installed and see if everything works ok.

I presume that the problem with the installer seeing the default session path as not writable has something to do with the security settings that Plesk puts in place, but in fact the web server will be able to save sessions correctly.

I didn't get a chance to test the script thoroughly on a server using Plesk.

[Anonymous]

A quick explain of how this works ... I think

php.ini defines three directives with the following defaults
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440

what this basically allows is for php to clean up your sessions without having to have a timed cron job or needing to run a cleanup task every time a new session is created.

When a new session is created the session handler rolls a random number and has a 1 in 100 chance (session.gc_probability / session.gc_divisor) of kicking off the Garbage Collection task (GC).

If it triggers the GC task php deletes all sessions files older than 1440 seconds (session.gc_maxlifetime).

These numbers may be different on your setup but the theory is the same.

I did the same session_save_path workaround for another peice of software that I run and the sessions do clear out after a while .... sometimes it clears after a few sessions .. sometimes the dice are against you and a few hundred sessions can build up before the lucky number one is rolled.

Obviously the more traffic you have, the more sessions get created and the higher the chance that the cleanup will run.
On the flip side, if you don't have much traffic you probably don't have enough cookies to warrent the effort of a cleanup very often, a session file may last for weeks if you only have a few session created per day.

At least that is my concept of how it works ... i am still learning this stuff.

feel free to correct me if I am wrong :)

Content visible to registered users only.

[james88]

This solution is acredited to Diablo84 who answers questions on Experts Exchange and is due to the coding within /install/index.php.

To clarify this case I am running a VPS with Plesk 7.5.2 reloaded. The error that comes up is due to this code in install/index.php

-----------------------------------------------------------------------------
$sspath = ini_get('session.save_path');
if(preg_match("`\d+;(.*)`", $sspath, $matches)){
$sspath = $matches[2];
}
if (! $sspath) {
$r['ok'] = false;
$r['txt'] = _L('Fatal <span class="item">session.save_path</span> is not set.');
$r['fatal'] = true;
}else if (is_dir($sspath) && is_writable($sspath)) {
$r['ok'] = true;
$r['txt'] = '<span class="item">('.$sspath.')</span>';
}else{
$r['ok'] = false;
$r['txt'] = _L('Fatal: <span class="item">##sspath##</span> not existing or not writable.');
$r['txt'] = str_replace('##sspath##', $sspath, $r['txt']);
$r['fatal'] = true;
}
-----------------------------------------------------------------------------

and in my case anyway - this creates an error that is NOT actually true

"Fatal: /var/lib/php/session not existing or not writable"

to remidy this, I have changed the above code to

-----------------------------------------------------------------------------
$sspath = ini_get('session.save_path');
if(preg_match("`\d+;(.*)`", $sspath, $matches)){
$sspath = $matches[2];
}

$r['ok'] = true;
$r['txt'] = '<span class="item">('.$sspath.')</span>';
-----------------------------------------------------------------------------

and all seems well!!! The install goes a dream.

Note: I also came across the same error trying to install Mambo on my server and I think this 'Fix' will sort that too.

Thankyou all for your postings.

[dcb]

In the next version I'll set this as a simple warning. Anyway if the sessions really don't work you won't be able to pass over the first installer page.

[james88]

All things said - this is an EXCELLENT script - keep up the good work :)