Hello,
I am using SuiteCRM V 7.12.5 on shared tenancy and i am trying to upgrade it to the latest version. When i am uploading the upgrade to the system (step 2) after a few seconds i get the following error:
Server timeout waiting for the HTTP request from the client.
Additionally, a 408 Request Timeout error was encountered while trying to use an ErrorDocument to handle the request.
Any suggestions?
Hi @gtheotokatos,
Welcome to the community! 
Could you send the link to where you downloaded the upgrade package and what its name was?
How much memory do you have on the system also?
Thanks!
Hello and thank you for your support.
This is where i downloaded the upgrade package, https://suitecrm.com/files/147/SuiteCRM-7.12/626/SuiteCRM-Upgrade-7.12.x-to-7.12.6.zip
Here are my system settings:
display_errors
Disabled
max_execution_time
300
max_input_time
300
max_input_vars
5120
memory_limit
64M
post_max_size
128M
session.gc_maxlifetime
1440
session.save_path s
/var/cpanel/php/sessions/ea-php80
upload_max_filesize
128M
zlib.output_compression
Enabled
Anyone who could help on this please?
That memory_limit at 64MB is not good. Try 256M or even 512M
Memory limit increase at 512M but nothing changed. When i am uploading the file i still get the same error 408 timeout
Did you restart web server after changing php.ini? Did you change the correct php.ini file (there can be mutliple files…)
You can check all this (paths, effective values) in Admin / Diagnostic / phpinfo
Thanks for the swift response. Unfortunately I am not able to restart the server as it is hosted in shared tenancy.
I can confirm that the change has taken place following the path you mentioned.
If the new value shows as effective in a phpinfo obtained from within SuiteCRM, then you should be ok. You can try increasing also max_execution_time.
There was a bug a couple of years ago that caused upgrades to become really slow and break. But this shouldn’t be a problem since you’re already on 7.12.5.
A symptom of that problem would be to find a lot of files under cache/upgrades/temp. I recommend you clear that temporary directory and restart the upgrade. This "clean start "is probably a good idea since you already had a number of failed upgrades.
I increased the execution time and the input time to 3000 from 300. I then deleted the content of the temp file and started fresh without any success.
Not sure if the log files will be any good but here is a copy:
versions: MySQL error 1146: Table ‘dbname_scrm2.versions’ doesn’t exist
Mon Jun 13 09:36:52 2022 [19823][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] ERROR: There was an error during upload. Error code: -
Mon Jun 13 09:39:22 2022 [30332][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] ERROR: There was an error during upload. Error code: -
Mon Jun 13 09:40:49 2022 [2035][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] Mysqli_query failed.
Mon Jun 13 09:40:49 2022 [2035][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] Query Failed: DESCRIBE versions: MySQL error 1146: Table ‘dbname_scrm2.versions’ doesn’t exist
Mon Jun 13 09:40:49 2022 [2035][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] Mysqli_query failed.
Mon Jun 13 09:40:49 2022 [2035][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] Query Failed: SHOW INDEX FROM versions: MySQL error 1146: Table ‘dbname_scrm2.versions’ doesn’t exist
Mon Jun 13 09:40:49 2022 [2035][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] Mysqli_query failed.
Mon Jun 13 09:40:49 2022 [2035][e2dd7c6e-959c-61f5-7045-606599777b85][FATAL] Query Failed: select * from versions: MySQL error 1146: Table ‘dbname_scrm2.versions’ doesn’t exist
Those errors are strange and they are probably the cause of your failed upgrade. Try searching for solutions to them first…
I cannot find a solution to these errors or upgrade to the latest version.
Does anyone knows if there is a way i can migrate all my data from V7 to V8? Export data from V7 and import them to V8 with csv is not working.
The next SuiteCRM 8.x version will be the first to include a migration path from v7 to v8. I really don’t advise attempting anything manually before that… just wait for a few weeks.
time is not an issue as long as i can update as currently i am not.
I don’t know if this helps, and I don’t know the consequences of you just copying this into your database, but if you have backups and are willing to take a risk, here is a copy of what that versions table looks like in a 7.12.5 installation I have:
-- phpMyAdmin SQL Dump
-- version 4.9.5deb2
-- https://www.phpmyadmin.net/
--
-- Host: localhost:3306
-- Generation Time: Jun 22, 2022 at 12:13 PM
-- Server version: 8.0.29-0ubuntu0.20.04.3
-- PHP Version: 7.3.29-1+ubuntu18.04.1+deb.sury.org+1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Database: `suitecrm`
--
-- --------------------------------------------------------
--
-- Table structure for table `versions`
--
CREATE TABLE `versions` (
`id` char(36) NOT NULL,
`deleted` tinyint(1) DEFAULT NULL,
`date_entered` datetime DEFAULT NULL,
`date_modified` datetime DEFAULT NULL,
`modified_user_id` char(36) DEFAULT NULL,
`created_by` char(36) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`file_version` varchar(255) DEFAULT NULL,
`db_version` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
--
-- Dumping data for table `versions`
--
INSERT INTO `versions` (`id`, `deleted`, `date_entered`, `date_modified`, `modified_user_id`, `created_by`, `name`, `file_version`, `db_version`) VALUES
('c3d3aa65-6d13-9565-689b-5731f9e38f49', 0, '2016-05-10 15:09:12', '2016-05-10 15:09:12', '1', '1', 'Rebuild Relationships', '4.0.0', '4.0.0'),
('d74c8489-d458-697e-9dae-5731f9de3c6c', 0, '2016-05-10 15:09:12', '2016-05-10 15:09:12', '1', '1', 'Rebuild Extensions', '4.0.0', '4.0.0'),
('de8b0f7c-410c-14df-8a6e-54c74bbf0ec5', 0, '2015-01-27 08:27:15', '2015-01-27 08:27:15', '1', '1', 'Chart Data Cache', '3.5.1', '3.5.1'),
('e22a292a-7795-6b70-630f-54c74b6c7a5f', 0, '2015-01-27 08:27:15', '2015-01-27 08:27:15', '1', '1', 'htaccess', '3.5.1', '3.5.1');
--
-- Indexes for dumped tables
--
--
-- Indexes for table `versions`
--
ALTER TABLE `versions`
ADD PRIMARY KEY (`id`),
ADD KEY `idx_version` (`name`,`deleted`);
COMMIT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
My database is called suitecrm, yours apparently is called dbname_scrm2, remember to change that.
Hello,
I would need to upgrade 7.12.5 to 7.12.6
Is the wizard a good choice to do it or there are possible issues/missing?
Once I wrote a post with some steps to help clarify/simplify the upgrade process for the 8 version,
but never received a full confirmation of its goodness. Then I switched back using the 7.12.5 version .
Now if the upgrade wizard is not reliable maybe those steps are applicable in this case?
Thanks
Mario
I think for 7.x → 7.x upgrades we should all really stick to the upgrade packages and the wizard. If the wizard doesn’t work then that is a sign of a problem that needs to be diagnosed and solved. It’s probably working for 99% of people, so maybe there’s something unhealthy about the specific installations where it fails.
For 8.x → 8.x upgrades maybe we can go with pulling from Github, I’ve done a few that way… the modern code lends itself better to that sort of strategy…
Many thanks, i will probably wait for the new version to come out and see if i can jump from 7.12.5 to 8.2. Not that techie 
If the upgrade is taking longer than 5 min then I would increase “max_execution_time” and “max_input_time”