I’ve read through the forums and tried pretty much everything I could think of. I have a test install which was on 7.10.x. I was able to upgrade it to 7.11.2. However, my production install is at 7.11.0 and I keep getting a 500 error on the 1st System check step. I’ve tried resetting permissions, removing files in the temp and upgrade dirs in cache, etc. I did this and it worked for the test install at 7.10.x.
The upgrade logfile shows:
Thu, 28 Feb 2019 09:43:54 -0600 [UpgradeWizard] - Upgrade started. At start.php
Thu, 28 Feb 2019 09:43:54 -0600 [UpgradeWizard] - at unlinkUWTempFiles()
Thu, 28 Feb 2019 09:43:54 -0600 [UpgradeWizard] - finished!
Thu, 28 Feb 2019 09:43:54 -0600 [UpgradeWizard] - resetting $_SESSION
Thu, 28 Feb 2019 09:44:01 -0600 [UpgradeWizard] - setting session variables...
Thu, 28 Feb 2019 09:44:01 -0600 [UpgradeWizard] - [At systemCheck.php]
Thu, 28 Feb 2019 09:44:01 -0600 [UpgradeWizard] - Starting file permission check...
I just ran it again and got a 405: Not Allowed error page. Can someone please help me get past this? Thanks.
I can’t restart the web server or see the apache log files as I’m on shared hosting. I did check the php.ini variables and they seem to be OK. The upgrade log doesn’t seem to get past the file permissions check even though I’ve reset them several times.
I’m still trying to work this out because the workflows are not working. Nothing changed in the .htaccess file so I doubt that’s it. I’m working with my webhost tech support right now but I’m not sure that will go anywhere. I’ve fixed file permissions and ownership multiple times. I’ve gotten 500 errors many times when I’ve tried to upgrade in the past but I’ve been able to get past it with chmod the permissions (not sure why that gets messed up). However, this time it’s just not moving forward.
I managed to upgrade to 7.11.13. I had saved previous versions of the upload directory and found that there were a lot of files in them so I deleted all the upload directories. The file permission check completed successfully and, although I still got a few 500 timeouts, the upgrade completed. However, workflows still don’t work or send out emails. I see a bunch of running status messages in a few workflows I looked at. How do I clear this out and get workflows working again? Thanks.
Are your cron jobs running as the same user as your web application? If not, that would explain the permissions getting messed up successively, and the Workflows having trouble running (the workflows run from CLI PHP, not web server PHP)
Yes, everything is owned and run by the same user. I did receive a workflow email yesterday so it seems it is working again. I have to do some more checking, though.
Can you tell me what files/dirs are not needed and can be removed from the SuiteCRM dir? It seems that the reason the file permission check may have been giving me the 500 error is that there were simply too many files to check? Removing the upload dirs allowed me to get past the check. I’m not 100% sure that was the cause but it does look like it. Removing unneeded files and keeping the main directory small is what I’d like to do. Thanks.
I think this is what my issue was. I removed a lot of files from cache/upgrade/temp which cut my dir size by more than 50% I think! Is there any other clean up I can do besides this to make it lean? Thanks.
I looked at the database tables while I was cloning my instance. I was amazed to see that my DB was like 15GB even though it doesn’t have that much data! What I found is that 2 tables are responsible and I can guess it has to do with the workflow issues from 7.11:
I am on .3 if you see my earlier post. I managed to update. This is what I’m seeing now and i’d like to know if I can empty or clean out these tables to reduce the sizes without messing up anything.
For the job_queue, you can delete all rows with state=done (or something to this effect) that are older than say, a month.
For aow_processed it is harder, more care needs to be taken if you have workflows that rely on the “no repeated runs” checkbox. If you just delete everything these workflows might be triggered again for the same records. Only you can assess if that is a problem according to your business requirements and the nature of the Workflows you designed.
There are some scripts there for clean-up, but please make sure you understand what you’re doing before starting to delete…
I am pretty sure that cleaning up these huge tables will make your workflows work again, it is very likely that they are just timing out when accessing those huge tables.