System Check failed with Internal Error 500, Upgrade not possible

📦 Install & Upgrade Help
1

Hello,
I plan an upgrade our SuiteCRM installation to an actual version.
However, the first step (System Check) leads to “Internal Error” after about 90s.

Last message in file upgradeWizard.log was “setting session variables…”

Repair function is done without errors besides a message “Differences found between database and vardefs”
I tried button “Execute”, but this error remains…

Diagnostic tool runs successfully besides the message “Table ‘my_databasename.versions’ doesn’t exist”. But this message should be ignored.

Actual Version: 7.11.7

special values in php.ini:

default_charset = “utf-8”
date.timezone = “Europe/Amsterdam”
upload_tmp_dir = “tmp”
max_execution_time = 300
post_max_size = 200M
upload_max_filesize = 100M
memory_limit = 300M
max_input_time=180

2

Please clear the “cache/upgrades/temp” directory (remove anything inside it) and try again. If it still doesn’t work, you need to wait for the version that includes this fix: https://github.com/salesagility/SuiteCRM/pull/8257

3

Hello pgr,
Before start of System Check this directory “cache/upgrades/temp” is empty.
After starting the System Check a file named “upgrade_progress.php” with size=0 was injected in the temp directory.
Nothing else happend till appearance of Internal Error.
Messages in UpgradeWizzard.log were

  • Upgrade started. At start.php
    Sat, 16 Nov 2019 08:57:07 +0100 [UpgradeWizard] - at unlinkUWTempFiles()
    Sat, 16 Nov 2019 08:57:07 +0100 [UpgradeWizard] - finished!
    Sat, 16 Nov 2019 08:57:07 +0100 [UpgradeWizard] - resetting $_SESSION
    Sat, 16 Nov 2019 08:57:13 +0100 [UpgradeWizard] - setting session variables…
    Sat, 16 Nov 2019 08:57:13 +0100 [UpgradeWizard] - [At systemCheck.php]
    Sat, 16 Nov 2019 08:57:13 +0100 [UpgradeWizard] - Starting file permission check…

I checked fix: github.com/salesagility/SuiteCRM/pull/8257
But I think this isn’t the reason of my problem.

Additional Hint:
Last year I installed a test installation of SuiteCRM, Version 7.11.5 in another environment but with same provider (Strato).
Now I did System Check and see a similiar problem:

  • Internal Error 500 after about 2 minutes.
    but, additional messages in upgradeWizard.log:
    • Starting File permissions
    • …
      Last entry:
    • Finished database permissions check.

May be this is a problem of central provider limitations?

4

The problem is the same as I describe in my Issue https://github.com/salesagility/SuiteCRM/issues/8261

but my fix is still incomplete, and it doesn’t cover the file permissions check that is breaking your system.

You need to

OR

  • increase your resources until it is able to go through the entire directory

OR (this is the easiest)

  • reduce directory size so it doesn’t crash. The relevant factor is not file size, but file count. Maybe go here and add “vendor” to the list of directories to exclude from check:

https://github.com/salesagility/SuiteCRM/blob/master/modules/UpgradeWizard/systemCheck.php#L56-L60


$skipDirs = array(
    $sugar_config['upload_dir'],
    '.svn',
    '.git',
    'vendor',
);

Watch out for a possible pitfall: sometimes you change these files, then the upgrades starts by putting new versions in place (removing your changes) and only afterwards does it execute those files. So try to make the changes immediately before the step where they’re getting executed.

5

Hello pgr,
I enhanced file "modules/UpgradeWizard/systemCheck.php at “skipDirs = array (…” with line ’ .vendor’,
But Upgrade is still not possible, because System Check furthermore leads to Internal Error.

What resources are the most important ones?

6

Hello pgr,
I analyzed the behaviour of the moduls “systemCheck.php” and “uw_utils.php”.
Internal Error 500 occurs in recursive routine "uwFindAllFiles ", line “rsort($theArray);”.
Not at one certain Dir but at different Dirs like

  • include//javascript//yui//build//button//assets//skins/
  • include//javascript//yui3//build//querystring/
  • include//javascript//yui3//build//dataschema/
  • include//javascript//yui//build//editor/
    So I think, the reason of Intenal Error 500 should be a lack of resources and I’ll try to find the limit.
7

Don’t put a dot “.” before vendor, just use the exact text I gave above.

8

Hello pgr,
Yes, that was my error.
Only a little point…
Now System Check is working and I try to do an Upgrade (after BackUp, of course)

9

Hello,
Unfortunately Internal Error occurs after System Check in one of the next step of upgrade wizzard.
But now I think I know the reason:
Provider Strato limits the number of files in one webspace to 260.000 files. As soon as number of files exceed this limit, writing additional files is prohibited!
I think, this strange behaviour is reason for many problems in several apps!

10

SuiteCRM doesn’t have 260k files, it has around 36k.

Only a repeatedly failed upgrade process (with the current bug) could bring you to that number, because of stuff inside “cache/upgrades/temp”. You should clear that directory again if necessary.

11

Hello,

The cache directory of my SuiteCRM installation really contained 150k files. This was caused by several failed upgrade processes.
Additional other apps like homepages and some test installations leads to more than 260k files

I deleted cache directory of SuiteCRM and started upgrade again.
System Check with excluded dir “vendor” runs successfully.

Internal Server Error, however, appears furthermore at uploading upgrade files, unzipping, preflight. After crash I start upgrade procedure again and it seems to make the next step…
But at the end I hang with “*** ERROR: no manifest file detected while bootstraping upgrade wizard files!”.
Looks like any limitation in Strato server. I extended some PHP limitations (see post above) but without success. May be there is another limitation. Or there is a limitation that cannot be extended.

12

I have fixed a couple of upgrade delays (which cause resource exhaustion): https://github.com/salesagility/SuiteCRM/pull/8257

To benefit from those changes you have to wait for the next release, or you can use those files but you need to put them inside the upgrade package, in the proper directories, before uploading the package into the upgrade wizard.

Another possible workaround is to remove the entire “vendor” directory from the package before starting. Then in the end you can run, from your SuiteCRM root:

composer install --no-dev

You might need to install composer before doing that.

A final possible workaround, if nothing else works: keep an eye on the cache/upgrades/temp directory, during each step of the upgrade process. You will see a few copies of the unzipped package appear there. You can immediately delete them, except the one referenced inside the upgrade_progress.php file. Note that this will change as steps advance.

Basically, you will be “taking out the trash” of each step early, instead of waiting for the end to throw everything away.

1 Like
13

Hello,
I did a lot of the proposals of this thread- But up to now I was not successfull with upgrading to new version.
I will wate or a new version.
Thanks to pgr for great support.