Support

Site Restoration

#32467 Kickstart does not start extraction process with PHP7.4

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Werner1
Hi,
Kickstart stopps Exctration-Process under PHP 7.4.2. Switching back to PHP 7.3.11 solves the problem...
Werner

nicholas
Akeeba Staff
Manager
Kickstart is developed on PHP 7.4. Moreover, all of my development environments are using PHP 7.4 by default. Your problem is not the PHP version (which would be something for us to fix).

Trying to help you on an issue that you self-misdiagnosed is really not possible since all I have is your wrong diagnosis :( If I had an exact error message and a screenshot from your issue I could help you identify the real issue and work around or fix it.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Werner1
Oh, congratulations that it worls on your systems!!! This makes me happy. As far as my websites are concerned, I have to switch back to PHP 7.3.
There is no error message. The "extracting sreen" is shown and there is no progressbar going ahead.
Thanks for your help. I appreciate it very much...
Werner

nicholas
Akeeba Staff
Manager
Thanks for the sarcasm, but it's both unwarranted and not conducive to me being able to help you. I am not disputing the fact that you have an issue, I am only disputing your diagnosis.

I have to work with 4 data points.

0. (this is something I JUST found out) The problem is that you see the extraction page with the progress bar but nothing seems to be obviously moving along and no error message is sent back.

1. I am developing and using Kickstart on a plethora of different local, staging and live servers using PHP 7.4. This spans every major operating system and web server software, not to mention a very representative real world mix of server environments. Therefore if there was a problem with something as fundamental as initiating the backup extraction -- an operation that literally EVERY use case of Akeeba Kickstart relies on -- I'd have certainly noticed given the fact that between developing, managing my sites and helping clients I am doing at least a dozen backup archive restorations a day.

2. The other reason that tells me that you have misdiagnosed the issue is that nearly 5% of our users are already on PHP 7.4. Based on my 13 years of experience, if there is a fundamental issue that affects at least 0.5% of our users we receive a plethora of tickets about it within the first 8 hours. It's been a quiet two days. The likelihood that you bumped into a PHP version incompatibility that nobody else could reproduce is infinitesimal.

3. You say that switching to PHP 7.4 stops the extraction dead but switching back to 7.3 fixes it.

The first thing that comes to my mind is "how exactly did he change the PHP version". If you used something that made a change to your .htaccess file or edited your .htaccess file directly we may have something there. The very first thing Kickstart does before the progress bar starts moving is rename .htaccess to htaccess.bak. If you see that file suddenly appearing then your problem is that your web server defaults to a PHP version earlier than 5.3.3 (the minimum PHP version Kickstart supports) which explains why you see nothing happening.

If the PHP version changes without touching any file under your site's root the answer might be in the different ways each PHP version is configured. Is one an Apache module and the other one implemented through FastCGI? That would imply there's a web server misconfiguration e.g. the wrong thread safety binary being used. Do both PHP versions have the same PHP extensions enabled? If not, maybe PHP 7.4 is missing something we are using such as JSON.

However, in both cases I'd expect to see an error message -- at the very least an AJAX Error after 30 seconds of nothing happening. Have you let it run that long?

If you have let it run for more than 3 minutes and literally nothing is happening I am suspecting a browser issue, possibly in combination with another server issue. However I cannot magically diagnose this; I would need to have access to an affected server.

So the information I need is:

1. How do you change the PHP version?
2. Is the .htaccess file in the site's root modified when you change the PHP version? If so, what are its contents for PHP 7.3 and PHP 7.4.
3. Have you confirmed that the PHP binary setup and php.ini configuration are identical in both PHP versions? If not, what are the differences?
4. How long have you let it run before deciding it's stuck?
5. Just to make sure, if you let it on the extract page for at least 180 seconds do you get ANY error message at all? If so, what is its exact content?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Werner1
First of all: I wanted to check my backsups for the event, the whole site is inaccessible.
1.: I deleted the site in the root folder.
2.: I uploaded the site by ftp ( yes, in binary mode)
3.: I uploaded the files kickstart.php ( I renamed this file) and en-GB.kickstart.ini
4.: I ran the (renamed) kickstart.ini
5: I skiped the first screen by pressing ESC and pressed start to extract the files
6: Nothing happened anymore - no display of errors, or display of any progress. I admit, I waited for about 90 seconds only, as with PHP 7.3. the extraction process begins instantly on thos server.

1. I changed the PHP-Version by means of the hoster's panel.
2.: .htaccess is not availble when doing an new install of theWebsite.
3. : Versions were different: Backup-Version was made in PHP 7.3. This was never an issue in the past.
4.: 90 sec., as the server is fast. IN PHP 7.3 the extrcationran instantly

Never mind the problem for the time being - I switched all websites back to PHP 7.3 and everything is running fine.

Werner1
To make item #2 clear: I uploaded the backupfile of the site ;-)

nicholas
Akeeba Staff
Manager
1. I changed the PHP-Version by means of the hoster's panel.

2.: .htaccess is not availble when doing an new install of theWebsite.


This is basically what I said before. When you use the hosting control panel what typically happens is that they add a line in the .htaccess file which changes your current PHP version. For example, you might see something like this at the bottom of your .htaccess file:
AddHandler application/x-httpd-php74 .php


However, when you click the Start button the .htaccess is renamed to htaccess.bak, therefore it is no longer applied. This means that your server falls back to its default PHP version.

Remember, at this time the Kickstart page is loaded on your browser and doesn't reload. But the JavaScript on that page still runs and tries to execute the next step by doing an XMLHttpRequest (AJAX) call to your server, i.e. it tries to load kickstart.php again.

If the server's default PHP version is too old for Kickstart that AJAX call will fail and you won't see the progress bar moving. I would expect to see an error BUT it may take up to 3 minutes for that to happen. That's why I had asked about how long you waited.

I still need to know what happens when you switch your site from PHP 7.3 to 7.4. Do you see a change or addition of an AddHandler or SetHandler line in your .htaccess?

There's a very good reason I am asking this, really. One of the items in my to-do list for this Spring is trying to modify Kickstart to preserve these AddHandler / SetHandler lines which set a specific PHP version instead of completely obliterating the .htaccess file prior to restoration. What I'm interested in is understanding if this would be something that would help in your case so I can better design this new feature. I really do care about making things easy for you guys. I've always said that Akeeba Backup doesn't make backing up, restoring or moving sites possible; it's only meant to do it easier. This means I get to contemplate on the challenges you have during those operations and try to provide as much automated features as possible to overcome them without too much effort.

Thank you in advance for your feedback!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Werner1
Hi Nicholas,
I have not much time today. I will answer your questions later. This might help you for the time
being, as I just spoke to an technician of
my Provider.
This is what je he says: The .htaccess is not changed by the Provider.
They run a cgi-script for the corresponding PHP-version on a higher level than my root folder is.
Werner

nicholas
Akeeba Staff
Manager
Thank you. That removes an entire branch of possibilities (one that didn't quite match my expectations – as I said, I'd expect an AJAX error).

This leaves me with a few possibilities regarding the server configuration.

Now that you have restored your site, if you switch it to PHP 7.4 do you observe anything being broken? If not, can you take a backup? If the backup fails can you please ZIP and attach the backup log file? The answers to these questions will give me a pretty good idea about the nature of the problem (missing PHP extension, wrong PHP binary, PHP-FPM / FastCGI misconfiguration or a process memory limit).

Sorry for all these questions. Typically these issues are far faster troubleshooting with direct access to the affected site but since this is not an option (we don't want to bring your site down) I have to resort to much slower, indirect information collection.

Alternatively, you can set up a subdomain for me to run a few tests and give me FTP access to it. If you decide to do that please let me know first so I can convert your ticket to private. Right now it's public and it's not safe to share connection information with me – everyone could read them.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Werner1
The site runs without problems on PHP 7.4.2.
Backup on PHP 7.4.2 was also made without problems.

On an attempt to restore the installation from the Joomla Backend, this error message was displayed:
Extraction failed
Extraction of Backupfile failed.
Last error message:
AJAX Loading Error
HTTP Status: 503 (Service Unavailable)
Internal status: error
XHR ReadyState: 4
Raw server response:
Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Switching back to PHP 7.3 did the job in the Joomla-Backend fast and without problems.


Trying to restore a backupfile in an empty rootfolder in a subdomain had the same result as described: I got the extraction page but the script seemed to be stopped withour an error message. After switching to PHP 7.3 the restoration was achieved.

Do you still need FTP-Access to the test-/subfolder? I would give you access as soon as the ticket is converted to private.

Werner

Werner1
Addendum: My hoster did not find any error logs in the system and told me, that akeebabackup seems not ro be compatibel to PHP 7.4.2 ....?

nicholas
Akeeba Staff
Manager
Akeeba Backup IS ABSOLUTELY AND MOST DEFINITELY compatible with PHP 7.4.2 on the grounds that this very site where we're haiving this conversation and all of my development sites, plus several thousands of client sites, all run on it perfectly.

Not only that, but if your host actually knew how his servers work and what is the connotation of the idiotic things they spout they'd be fully aware that if there was a PHP version compatibility issue they would have of course seen a PHP error log entry (and most likely an Apache error log entry) describing the PHP Fatal Error that would have occurred.

Unfortunately for your host, I have been testing Akeeba Backup with PHP 7.4 since PHP 7.4 was in beta! I know that they only compatibility issues it had were non-fatal: a few continue statements that should have been continue 2 and some legacy code that was using curly braces string array access instead of square braces. By the time PHP 7.4 was in Release Candidate 1 we had already converted all our commercially available software to be fully compatible with PHP 7.4. Because, unlike your host, we actually know what we are doing.

Now, let's see something very important that came out of the test I asked you to run. We have a smoking gun! Lo and behold:

HTTP Status: 503 (Service Unavailable)


This proves beyond any shred of doubt that the problem is none other than your host. This is the error you get when mod_fcgid or mod_proxy_fcgi sees the PHP FastCGI binary / PHP-FPM server crash or cannot connect to it at all (I suspect the former over the latter since your site DOES run under PHP 7.4). This is what you see when the server administrator has screwed up the configuration of the server.

Unfortunately for your host I happen to not only develop PHP software but also know how to set up server. I mean my macOS server setup (which is easily adaptable to Windows and Linux) is not exactly secret. A sort walk through my blog will be proof enough of how much I've learned about server setup the last ten years. But I digress.

If your host is using PHP-FPM I'd suggest that they take a closer look at its pool setup.

If your host is using plain old FastCGI with mod_fcgid I'd suggest that they check whether they are accidentally using the wrong thread-safety binary (which one they should be using depends on their Apache MPM).

As for why this issue is happening during extraction and not during backup, I have some theories but without the full server setup they will only be speculation. Let's just say that my experience on where to look can be found above.

In the meantime you can try to work around your broken server environment by adjusting the Kickstart / integrated restoration timing parameters. Maximum 3 seconds / minimum 1 if my first hunch is right, maximum 2 / minimum 5 (yes max is less than min on purpose) if my second hunch of what is going on is right.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Werner1
Ok, thanks for the information. I will forward this to my host, hoping they will fix it.
Thanks again,
Werner

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.