PDA

View Full Version : Session Save Path


atomicnuke
02-20-2006, 07:19 PM
I was creating a php script to find visitors currently on the site, by counting sessions. However I see the session.save_path in the php.ini file is set to store them in the same place for everyone. Which means it shows 2116 visitors last time i ran the script, which is wrong. How can I change it to store the sessions somewhere in my root or public_html folder? Everytime I tried it still showed the huge number.

Asking here, because bluehost has yet to get back to me.

atomicnuke
02-21-2006, 10:51 PM
Anyone? Bluehost has yet to respond which is surprising.

2notch
02-21-2006, 11:21 PM
Shot in the dark here.

Look at php.ini in your root folder about line 430:
[SESSION]
session.save_path = /tmp
*This seems to work with session.handler right above it*
*Also has to be copied to every directory you want it to work in*

You might be able to change this to a directory on your domain?

atomicnuke
02-21-2006, 11:29 PM
You think I should change it to like home/sitename/public_html/sessionfolder then copy that into all directories dealing with sessions?

2notch
02-21-2006, 11:54 PM
Yep. I think the /tmp folder is the one for the whole box so specify the entire path to your folder.
If it screws up something on your site you can just take it out.

atomicnuke
02-22-2006, 12:18 AM
That was my problem, I didn't copy it into the directory of the page running it, it works just fine. If someone else ever needs to do this, I couldn't get it to work with the home/sitenmae/public_html/sessionfolder method. I just used ../sessionfolder and it worked fine. Thanks for the moving the file advice 2notch!

atomicnuke
02-22-2006, 12:53 AM
The sessions don't seem to delete though. Every time I open the browser it adds to the visitor count, logically, since it is a new session. The default value a session stays is 1440, so I changed it to 300 (5min). But they don't seem to be deleteing.

session.gc_probability = 1 ; percentual probability that the
; 'garbage collection' process is started
; on every session initialization
session.gc_maxlifetime = 300 ; after this number of seconds, stored
; data will be seen as 'garbage' and
; cleaned up by the gc process

2notch
02-22-2006, 10:11 AM
Is the session actually being torn down or is it still alive after someone logs off?
I'm going to have to dig into this further now, its getting harder to figure this out.
(the session time out signal is not being seen by *your* session handler?, maybe?)

atomicnuke
02-22-2006, 03:06 PM
Yeah, I'm confused too, I sent them a ticket asking for help on the situation. If php.ini know where to save them and that works, don't understand why it can't delete them. It's like there is no GC happening or it is lost. Might be awhile though, last time they didn't even answer. This ticket is due Fri, didn't they move to 24*6? For how critical time is with websites, I'd think they could get back quicker.

2notch
02-24-2006, 09:03 PM
One thing about the session garbage collection, it doesn't seem to start until a new session is initialized. Even then, if the probability is set to 1, it may take a hundred new session initializations before it actually starts. Some notes indicate probability could be set to 1000, increasing the likelyhood that gc starts.

Here are some more notes on session garbage collection:
http://www.webmasterworld.com/forum88/11440.htm

I'll keep looking...

atomicnuke
02-24-2006, 10:05 PM
That's kind of messed up, I just thought the GC took care of them automatically, not through probabilty. What if I just right a script that runs everytime a new browser is active, so it deletes the sessions without relying on PHP GC. Think that would be better?

2notch
02-24-2006, 10:17 PM
Either that or run a cron job every 5 minutes that calls a php script with GC. I think there are some examples at php.net.

atomicnuke
02-24-2006, 10:19 PM
I made one because I was fed up, lol. Guess I'll just go that route, thanks for all the help 2notch. Can you believe bluehost has yet to even respond?

2notch
02-24-2006, 10:38 PM
It is strange that they haven't responded yet. I wonder if they take on the tickets sequentially or if they "triage" the tickets and work the more serious ones first (not that yours wasn't serious).

I've been lucky so far. I have been able to fix things myself and not had to turn in a ticket. Most of the stuff I do for the web I do on my CentOS web server at home before uploading. That way I kind of know what to expect.

This session stuff has been a good learning experience for me though.