You have been logged out because your session has expired.

I just installed suitecrm on a machine that had a sugarcrm6.5.16 installed and running for quite some time. No problems.

fedora 20 (Heisenbug) with latest updates
php 5.4.21

Up until the install of suitecrm (today) - I did not have any problems with session timeouts. All of a sudden when I log in and even while entering data, the session expires and I have to log in again. The sessions last maybe 1 minute and then logs out.

I poked around the sugarcrm forums. The problem does show up in the sugar forums however there doesn’t seem to be any clear indication of what causes the problemn nor a solution. There are some references to permissions, php.ini session timeout values but I don’t think any of that changes with the installation of suiteCRM … but I’m no expert. I’m wondering if the php.ini file that existed for the sugar instance was overwritten by the suite instance install. ??

I noticed during the suitecrm install that there was an option for a unique-session id or something like that… but didn’t think anything of it because right now I’m the only user of this system and so interfering with other users or them interfering with me isn’t an issue … or so I thought…I’m going to rethink that now anyway and do a re-install. By the way … anyone know how to re-initiate the install script as though it were a fresh install?

I can re-install suitecrm since there’s no data in the database. The MYSQL databases are separate and I wouldn’t even THINK about migrating sugar to suite until this is resolved. My intention though is to abandon sugar and go with suite because it’s got the reporting and workflow which I need.

Can someone point me in the right direction here.

Not only do I not have a workable SuiteCRM but the SugarCRM is exhibiting the same problem so I’m crippled right now.

Thanks everyone.

You might want to check these two settings in your PHP.ini file:

session.gc_maxlifetime 3600
session.cookie_lifetime 3600

Those helped me extend the short timeout, anyway.

There are some other settings in PHP.ini and config.php that are related to database query timeouts and max upload times; those may help too.

Further testing reveals that this problem is occurring only when both a SugarCRM and SuiteCRM are opened. The databases are different although hosted on the same machine. I think it must be some sort of session related issue between the two systems. Perhaps a re-install of Suite this time selecting the option to create unique session information would solve this. If I get a chance to re-install, I’ll try that.

I wonder if it’s a temp folder issue? When setting up the new instance, you may want to explicitly define alternate temp/cache folders for each installation.

It seems plausible to me that, because both systems are “technically” SugarCRM, there may be similar or identical files in the cache - and it may be confusing one or both installations.

Thanks amerisurg… Where would I set that?

It’s during the installation process. There will be an “advanced” setup where you can specify additional options.

I think you can also do it manually with an existing installation by modifying temp_dir in your config.php. Or, you can create a custom PHP.ini and drop it into your site’s root.

I could be completely wrong about those, but I think that’s what I’ve read. Or something very similar.

If I want to do a re-install from scratch - how do I do that?

Delete your server files and delete your database, and start over?

If you are using PHP 5.4 (and maybe 5.3) you can use a .user.ini file. (note the leading dot… it is a hidden file) and put it in your SuiteCRM directory.

Create a folder (directory) in the Suite directory called something like temp-suite.

In the .user.ini file put this:

session.save_path = temp-suite

You should not time out if you are also running Sugar. The only issue is that i’m not sure that PHP ‘garbage collection’ routines ever hit that file to clean it out of old sessions. it doesn’t seem to do it for me. I don’t know why but I’m seeking to find out. Maybe it only does it on the temp file that is listed in the php.ini file?

I found this note in the php.ini for my PHP 5.4.x install:

; After this number of seconds, stored data will be seen as ‘garbage’ and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

; NOTE: If you are using the subdirectory option for storing session files
; (see session.save_path above), then garbage collection does not
; happen automatically. You will need to do your own garbage
; collection through a shell script, cron entry, or some other method.
; For example, the following script would is the equivalent of
; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
; find /path/to/sessions -cmin +24 | xargs rm

So that answers that.

Thank you, yes , I saw that as well and did make that change. It didn’t solve the problem. I think I’m going to reinstall. I have another open case that the crontab entry for running the workflow isn’t working either and so I’m going to re-install the package in another directory that isn’t underneath the bitnami sugar instance and see if that resolves these two issues.

I’ll update this post once I’ve had a chance to re-install and test.

Run it on php 5.3…5.4 is unsupported as of this time. I’m sure this will solve your problem.

Maybe that will work, but maybe not. I’m using 5.5.7, personally, and I don’t have any PHP issues at all.

I’ve been running 5.4.2x for the past two weeks and have not had any errors or warnings thrown by SuiteCRM. From what I hear 5.3 is going EOL in a several months or perhaps early next year.

5.4 has been out for over a year and from what I can tell it is well tested.

I had upgraded my install to 5.5 and had issues with missing fields in studio and module builder.