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.
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.
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 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
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.
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.