Diagnostic Tool Hangs?

đź’¬ General Discussion
1

Hi All,

I just finished with a new installation of SuiteCRM 7.1.1 on Ubuntu Server 14.04. The installation went smoothly with no warnings or errors but when I try and run the Diagnostic Tool from within SuiteCRM then it just hangs at 15%.

Anybody know what all is being checked by the diagnostic tool and more specific what could typically make it hang like that?

Thanks for your assistance.

Werner

2

Hi Werner,

Have you checked your error log? Did you set permissions/perform a Quick Repair & Rebuild after installation?

Thanks,

Will.

3

Hi Will,

Yes, performed a Quick Repair and Rebuild and the results came out clean. Also checked the sugarcrm.log file in site root and the only error it contained was a non-fatal date.timezone error in php.ini. I correct this and re-did the QR&R and Diagnostic tool still hangs after that. It very quickly moves through several steps until it gets to the DB schema check and then hangs.

Permissions were set and checked according to the installation instructions on your site and I have had no other issues with permissions so far so the assumption is that its okay.

Is there any other log file that I don’t know about that may contain more indepth debug messages perhaps?

Werner

4

Turn on error reporting in php and see what goes wrong.

5

Might it be related to a PHP timeout? The default is I think 30 seconds, which in my case caused diagnostics and uploads and stuff to fail just about every time.

6

Some feedback… the Diagnostic Tool problem, together with a couple of other more obscure problems actually all came back to PHP 5.5 support (or at least lack of it in SCRM 7.1.1).

I rebuilt the whole environment with Ubuntu Server 14.04 and a down-graded Apache (2.2) and PHP (5.3) installation and that solved all of the previously experienced problems :slight_smile:

So for now at least I guess we will have to wait for SCRM 7.2.0 to come out with the roadmap-planned support for PHP 5.4 and 5.5.

Werner

7

I’m not convinced that all of the problems that get blamed on PHP 5.4 and 5.5 are actually true, or if it’s just a scapegoat for not really knowing what the problem is. I’ve been on PHP 5.5.7 since the beginning, and I’ve fought with my share of bugs, but in no cases have I ever been able to fix them by downgrading to PHP 5.3.

PHP 5.4+ “not being supported” is not the same as “incompatible”. The differences between versions are not as great as some would like us to believe.

I personally don’t have any problems with the diagnostic tools. So we can’t really say that PHP was the root cause, because it doesn’t affect me and it doesn’t affect many of the other people already using it.

8

Fair enough, you may be correct. It may not be the root cause of all the problems blamed on it, but in the event of the problems that I personally experienced, it was definitely the only factor that was different between the test beds used. I work in a very tightly controlled test/dev environment and everything gets documented meticulously in the process, so by a mere process of elimination and deduction that was the only variable that changed, and thus the only variable to be blamed.

Admittedly I was looking at the testing in this particular case from an administator’s view and not from a coder’s view, so no real time was spent on digging into the code too much to look at debugging traces, etc. I have to get to a working, stable environment asap, and if that meant downgrading certain components to get to a state known to be supported by the code devs, then so be it. In this case, time is money is the over-riding principle, and not for the love of making it work on the latest and greatest beyond all costs :slight_smile:

Werner