session times out well before it should

[ergophobe]

what determines how long a session remains valid?

I have a site where all pages require login. The user should stay logged in as long as the session is valid. It was logging people out in much too short intervals, so I added to the .htaccess:

php_value session.gc_maxlifetime 72000
php_value session.cookie_lifetime 72000

I thought those values should certainly show whether or not it works and the answer is that it doesn't. If you let the browser sit idle for? it requires relogin (it's hard to test, since you have to wait so long).

The problem is, that's how the site is used - it's the interface to a database that people want to consult occasionally during the day. I want them to be able to open the browser and leave the DB in a window or tab and not have to log in if they don't use it for a couple of hours.

At the same time, it is essential to control access, so I can't just remove the login.

[WhosAWhata]

are you against just setting a cookie?
or if your sessions aren't working, you could make a
function...

function mysession(){
$open = fopen("log.txt",a);
fputs($open,time())
}

obviously MUCH more intricate, but i can't see that as a very feasible idea

[andylarks]

Session timeout is declared in php.ini

<snip>
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
</snip>

Hope that helps

[coopster]

ergophobe, I know you do your research, so I am going to restate a few points for the sake of clarity and for others that come across this thread. Then a couple ideas that you may want to check...

php_value session.gc_maxlifetime 72000

This should allow the session to "live" for at least 20 hours (72,000 seconds), even without any activity. After that, the session may or may not be "cleaned up" upon the next session registration process -- by your site or any other site sharing the same session.save_path [php.net] (probably

/tmp

) directory. The reason it may not be cleaned up is the garbage collection directives (session.gc_probability [php.net] and session.gc_divisor [php.net]). The default is a 1% chance that the session garbage collection routines will be initiated upon any given PHP session initialization.

In this particular case, it is just the opposite -- why are the sessions being cleaned up prematurely? I'm not sure. Off the top of my head, there are a couple of areas that we might troubleshoot...

• Are you certain that the .htaccess file is being processed? A quick check would be to throw a phpinfo() function in that directory with the .htaccess file.
  
• Is the shared host running some other type of automated job to do some server-side cleanup outside of PHP's own session garbage collection routines?
  
• What version of PHP is the shared host running? There are quite a few bug reports for prior versions.

BTW, session.cookie_lifetime [php.net] could be set to a value of 0 (zero), which will keep the session on the user side until the browser is closed. Unless, of course, you are planning on some people inadvertently closing their browsers :)

[jatar_k]

keep in mind too that the php session is at the highest level

could be an apache timeout
could be a tcp timeout

won't matter what php thinks, or is set to, if the timeout is somewhere else

[coopster]

I'm not tracking, jatar_k. Are you stating that an Apache timeout or a TCP timeout will cause the PHP garbage collection routine to fire off?

[jatar_k]

no but if you got a new session from either of those places there would be no association with the php session and therefore you would not be able to connect the session data with that user. So they end up with a new php session as well.

[ergophobe]

[edit]I was posting this while JK was explaining his previous post. Lights go on! That makes sense. What am I looking for though - not the HTTP timeout, but what?

PS Connection Timeout is set to 300 seconds. Now that finally sounds right, albeit a bit on the short side.
[/edit]

Is the shared host running some other type of automated job

That's a darn good question and that's the sort of thing I was scratching for. It's possible they are cleaning out the /tmp evrey so often and perhaps I need to change the session save path. I think I'll try that first and then get back to you.

won't matter what php thinks, or is set to, if the timeout is somewhere else

Not sure I follow. The page does not time out when loading. "Logged in" status is checked by looking at session variables. After a certain amount of time, they're gone and the user is no longer logged in. So how would an Apache timeout affect that? FYI

keep-alive timeout=15 max=100

I don't think that's it, but I'm definitely open to suggestions.

And, since there were a lot of other questions....

Are you certain that the .htaccess file is being processed?

Should have clarified. I ran phpinfo(), changed the .htaccess settings and ran phpinfo() again. All settings are changed as expected and are in fact set to 20 hours. And yes, GC is set to 1% so it shouldn't happen all the time, but it does.

BTW, session.cookie_lifetime could be set to a value of 0 (zero)... people inadvertently closing their browsers :)

Well, it was by default and, yes, I would rather have the session remain after the browser closes so that, if possible, a user would be able to resume a session upon showing up at work the next morning.

are you against just setting a cookie?

Not at all, though in theory that's what I'm doing when setting a session (I am forcing these sessions to use a cookies only. This is a non-public site and I can demand that of the users who will log in).

Session timeout is declared in php.ini

Or in .htaccess, which I did - set it to 20 hours.

[coopster]

I must still be missing something -- how would one get a new session from either of those places? Let's start with Apache...

If Apache reaches a timeout (assuming you mean a request timeout here) or even if the Apache server is rebooted, the session file still remains in the /tmp directory. And, the session id still remains in the browser cookie. Once the stateless connection regains connection when the browser requests the page and the server is ready to respond (hopefully well under the 20 hours alotted, or find a new host), the server will check the session id and all is well again...

You're going to have to walk me through this as I'm not connecting yet. It seems I may be having a timeout...:)

[ergophobe]

Actually, I have to say, I was happy to have some direction, but after posting my edit, I have to agree with coopster. Isn't it just matching the session id from the cookie with the session in /tmp?

Anyway, I'll change the session save path as a first step and see what happens.

[ergophobe]

Changing the session.save_path seems to have done it, so coopster's hunch was correct.

Thanks everyone!

Tom

[jatar_k]

I thought of this thread today while readin the changelog for php 4.3.6, one of the fixes was the below

Fixed bug #26757 [bugs.php.net] (session.save_path default is bogus for win32).

[ergophobe]

Just for the record, that wasn't my particular problem. In fact, my problem was on a *nix machine. The problem was that it was on a shared host and the system was cleaning sessions out of the /tmp every ten minutes or so. So I had to set the session.save_path to something *other* than the system temp directory.

Tom

[jatar_k]

I couldn't remember if you were on *nix or not but I thought it was worth a mention.