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.
; http://php.net/session.gc-maxlifetime
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.