Time before auto log out is very short - how to fix?

[freephile]

The default session lifetime (garbage collection) in PHP is 24 minutes. See http://us2.php.net/manual/en/session.configuration.php

You can find the setting for your server in your PHP configuration file. e.g.
grep -i session.gc_maxlifetime /etc/php5/apache2/php.ini

Either change this setting for your server or manipulate it through .htaccess for your application.

Changing the value to 28800 would make it 8 hours. e.g.
(in php.ini)
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 28800

(restart apache to reload the php.ini)
sudo apache2ctl configtest
sudo apache2ctl graceful

[casyi]

hello sir,, can you help me with my problem regards to
web to lead form???
when submitting my form on web it direct always to login page of my sugar crm... cant find a way
whats wrong ...
using webtoleadCapture.php and it came to log out not a thank you page...
what suppose to be a problem???
sorry im a new here in sugar and i want to learn it.. thanks in advance..

Hi danad, we use Sugar all day long and there is no auto-logout. I don't know off the top of there is a such a setting on config.php and manipulated thru Admin->Settings.

But ... if you IP changes, you'll be forced to log in again. Are you seeing this?

Andy

[datasponge]

Here's something else that might be valuable to someone out there. Some Linux flavors handle garbage collection differently than others. I tried freephile's instructions and verified them with phpinfo(), but they did not fix my problems. On Mandriva and possibly other flavors of Linux garbage collection is done through cron.

Here's the history starting with freephiles valuable advice:

The default session lifetime (garbage collection) in PHP is 24 minutes. See http://us2.php.net/manual/en/session.configuration.php

You can find the setting for your server in your PHP configuration file. e.g.
grep -i session.gc_maxlifetime /etc/php5/apache2/php.ini

Either change this setting for your server or manipulate it through .htaccess for your application.

Changing the value to 28800 would make it 8 hours. e.g.
(in php.ini)
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 28800

(restart apache to reload the php.ini)
sudo apache2ctl configtest
sudo apache2ctl graceful

I was still getting session timeouts in some inconsistent range.

After intermittent research over a long period of time, I discovered that my system handles garbage collection differently and I followed some clues to find and resolve it.

In php.ini on my Mandriva Linux 2008 system I discovered the following comment:

; This is disabled in the Mandriva Linux packages, due to the strict permissions
; on /var/lib/php. Instead of setting this here, see the cronjob at
; /etc/cron.d/php, which uses the session.gc_maxlifetime setting below

I followed the path given and the crontab line in that file was:

09,39 * * * * root [ -d /var/lib/php ] && find /var/lib/php/ -type f -mmin +$(/
usr/lib/php/maxlifetime) -print0 | xargs -r -0 rm

So my Mandriva system is doing garbage collection at 9 minutes after the hour and 39 minutes after the hour every hour of every day. But it is referencing maxlifetime, so the settings given by freephile should still be used. But following the path given, I found that the executable file maxlifetime did not simply extract the gc_maxlifetime setting from php.ini - it also enforced a maximum value of 1440.

Here's that script. Note the max=1440 line.

#!/bin/bash -e

max=1440

cur=$(sed -n -e 's/^[[:space:]]*session.gc_maxlifetime[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p' /etc/php.d/*_session.ini 2>/dev/null || true);
[ -z "$cur" ] && cur=0
[ "$cur" -gt "$max" ] && max=$cur

echo $(($max/60))

exit 0

To verify that this was what was happening, I opened a session at 12 and left it idle until 12:39 when garbage collection was scheduled. At 12:40, I clicked a link in Sugar and was taken to the login page.

So that appeared to verify that this was causing the early timeout.

I changed the line to:

max=86400

(24 hours)

Now with freephile's changes, the garbage collcetion no longer terminated the session.

Phil