Web Setup Wizard stuck after failed rollback

damianduffy · February 18, 2019, 12:05pm

So the developer basically ranted about how long it takes to update the module on Magento Marketplace and said I need to manually re-install.

I went into the Web Setup Wizard and tried to disable the module (Stripe Subscriptions and Payment Gateway by Magenest). The disable process failed but I’m not sure why. It seems to have stopped at the point where maintenance mode was to be re-enabled.

Going into the process here’s my setup:

Magento CE 2.3
PHP 7.2
Stripe Payment Gateway and Subscriptions Module v100.5.5 (installed via Web Setup but trying to uninstall so I can install v100.5.7 via CLI)
Developer mode enabled
Maintenance mode enabled

Console Log from attempts to disable:

[2019-02-18 11:47:02 UTC] Job "setup:maintenance:enable []" has started
Enabled maintenance mode

[2019-02-18 11:47:02 UTC] Job "setup:maintenance:enable []" has been successfully completed
[2019-02-18 11:47:02 UTC] Job "setup:cache:disable []" has started
Changed cache status:
config: 1 -> 0
layout: 1 -> 0
block_html: 1 -> 0
collections: 1 -> 0
reflection: 1 -> 0
db_ddl: 1 -> 0
compiled_config: 1 -> 0
eav: 1 -> 0
customer_notification: 1 -> 0
config_integration: 1 -> 0
config_integration_api: 1 -> 0
full_page: 1 -> 0
config_webservice: 1 -> 0
translate: 1 -> 0
vertex: 1 -> 0

[2019-02-18 11:47:02 UTC] Job "setup:cache:disable []" has been successfully completed
[2019-02-18 11:47:02 UTC] Job "setup:module:disable {"components":[{"name":"Magenest_Stripe","isComposerPackage":true}]}" has started
The following modules have been disabled:
- Magenest_Stripe

Cache cleared successfully.
Generated classes cleared successfully. Please run the 'setup:di:compile' command to generate classes.
Info: Some modules might require static view files to be cleared. To do this, run 'module:disable' with the --clear-static-content option to clear them.

[2019-02-18 11:47:04 UTC] Cleaning generated files...
[2019-02-18 11:47:06 UTC] Complete!
[2019-02-18 11:47:06 UTC] Clearing cache...
[2019-02-18 11:47:06 UTC] Complete!
[2019-02-18 11:47:06 UTC] Job "setup:module:disable {"components":[{"name":"Magenest_Stripe","isComposerPackage":true}]}" has been successfully completed
[2019-02-18 11:47:06 UTC] Job "setup:cache:enable ["config layout block_html collections reflection db_ddl compiled_config eav customer_notification config_integration config_integration_api full_page config_webservice translate vertex"]" has started
Changed cache status:
config: 0 -> 1
layout: 0 -> 1
block_html: 0 -> 1
collections: 0 -> 1
reflection: 0 -> 1
db_ddl: 0 -> 1
compiled_config: 0 -> 1
eav: 0 -> 1
customer_notification: 0 -> 1
config_integration: 0 -> 1
config_integration_api: 0 -> 1
full_page: 0 -> 1
config_webservice: 0 -> 1
translate: 0 -> 1
vertex: 0 -> 1
Cleaned cache types:
config
layout
block_html
collections
reflection
db_ddl
compiled_config
eav
customer_notification
config_integration
config_integration_api
full_page
config_webservice
translate
vertex

[2019-02-18 11:47:06 UTC] Job "setup:cache:enable ["config layout block_html collections reflection db_ddl compiled_config eav customer_notification config_integration config_integration_api full_page config_webservice translate vertex"]" has been successfully completed
[2019-02-18 11:47:06 UTC] Job "setup:maintenance:disable []" has started

[2019-02-18 11:47:06 UTC] An error occurred while executing job "setup:maintenance:disable []": Could not complete setup:maintenance:disable [] successfully: Magento maintenance mode was not disabled. It can be disabled from the Magento Backend.
[2019-02-18 11:48:03 UTC] There was an error in previous Update attempt.
[2019-02-18 11:49:02 UTC] There was an error in previous Update attempt.
[2019-02-18 11:50:02 UTC] There was an error in previous Update attempt.
[2019-02-18 11:50:14 UTC] WARNING: There is a problem with backup files! Performing rollback from these files may cause the Magento application to be unstable
[2019-02-18 11:50:14 UTC] Backup file does not exist for "db"
[2019-02-18 11:51:02 UTC] Job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_code.tgz"}" has been started
[2019-02-18 11:51:02 UTC] Restoring archive from "{magento_root}/var/backups/1548790808_filesystem_code.tgz" ...
[2019-02-18 11:51:25 UTC] An error occurred while executing job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_code.tgz"}": tar-based phar "{magento_root}/var/backups/1548790808_filesystem_code.tar" cannot be created, filename "vendor/magento/module-inventory-admin-ui/Test/Mftf/Test/AdminMassActionTransferInventoryToSourceTransferringNotifyQuantityForDifferentTypesOfProductsTest.xml" is too long for tar file format
[2019-02-18 11:51:25 UTC] Job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_media.tgz"}" has been started
[2019-02-18 11:51:25 UTC] Restoring archive from "{magento_root}/var/backups/1548790808_filesystem_media.tgz" ...
[2019-02-18 11:51:29 UTC] Job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_media.tgz"}" has successfully completed
[2019-02-18 11:52:04 UTC] There was an error in previous Update attempt.
[2019-02-18 11:53:02 UTC] There was an error in previous Update attempt.
[2019-02-18 11:54:01 UTC] There was an error in previous Update attempt.
[2019-02-18 11:54:22 UTC] WARNING: There is a problem with backup files! Performing rollback from these files may cause the Magento application to be unstable
[2019-02-18 11:54:22 UTC] Backup file does not exist for "db"
[2019-02-18 11:55:01 UTC] Job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_code.tgz"}" has been started
[2019-02-18 11:55:01 UTC] Restoring archive from "{magento_root}/var/backups/1548790808_filesystem_code.tgz" ...
[2019-02-18 11:55:29 UTC] An error occurred while executing job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_code.tgz"}": tar-based phar "{magento_root}/var/backups/1548790808_filesystem_code.tar" cannot be created, filename "vendor/magento/module-inventory-admin-ui/Test/Mftf/Test/AdminMassActionTransferInventoryToSourceTransferringNotifyQuantityForDifferentTypesOfProductsTest.xml" is too long for tar file format
[2019-02-18 11:55:29 UTC] Job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_media.tgz"}" has been started
[2019-02-18 11:55:29 UTC] Restoring archive from "{magento_root}/var/backups/1548790808_filesystem_media.tgz" ...
[2019-02-18 11:55:32 UTC] Job "rollback {"backup_file_name":"{magento_root}/var/backups/1548790808_filesystem_media.tgz"}" has successfully completed
[2019-02-18 11:56:04 UTC] There was an error in previous Update attempt.

Current status:

I can’t get back to any other sections within the Web Setup Wizard and the rollbacks are failing. Is there a way to manually clear this down?

Thanks!

digitalstartup · February 18, 2019, 3:41pm

First things first… According to your logs, the module disabled successfully As you said, it fell down when it came to take your store out of Maintenance Mode because it didn’t put you in that state to begin with (for whatever reason). The fact Magento then told you to do a rollback is a bit like telling you to take your car back to the dealership because you ran a red light. Completely unnecessary.

Going back to the logs, your store should have worked just fine without the need to take any further steps. As you’ve already attempted to run a rollback, which has then ironically caused its own issue then I’ll focus on that.

So, it appears that a full rollback is failing because of the below reason - Which is really odd. Not the fact that the filename is too long because I have seen that happen before… But Magento naming files in such a manner that would cause it:

filename “vendor/magento/module-inventory-admin-ui/Test/Mftf/Test/AdminMassActionTransferInventoryToSourceTransferringNotifyQuantityForDifferentTypesOfProductsTest.xml” is too long for tar file format

However, I didn’t think a failed rollback caused any issues. Luckily, not all is lost. You’ll just need to SSH at this point.

What I could do with knowing first…
Before you do anything I mention below, can you tell me what you see when you attempt the following. If it doesn’t load as expected, what do you see instead when you:

Load the Frontend
Login to the Backend*
Revisit the Web Setup Wizard*

*Do this incognito in case your cookies do something odd

Thoughts
As I mentioned before, the module disabled fine (according to the logs) and the warning you received was a bit misleading. The error that got highlighted was insignificant and definitely didn’t warrant a rollback. So, that’s “good”.

You then received an issue with the rollback. But going back to my experience, I’m pretty sure that a failed rollback has no lasting issues on your store other than a warning.

However, you now have limited access to the Web Setup Wizard, which I’ve experienced before but was able to resolve by simply logging out/in the Magento again because of cookie timeouts. (A reason why I stopped using Web Setup Wizard and do everything via SSH now.)

In the next section, I’ll talk about SSH Rollbacks but before you work through that can you let me know the answers to the section above. I don’t think you need to run a rollback at all. If you’re store isn’t working as expected right now then there less “harsh” options to take first. But I’ll be able to be more specific based on your answers.

SSH Rollbacks
After logging into your server via SSH make sure that you:

Switch to your magento user
Navigate to the magento root directory

Next, you’ll want to display a list of current backups that you have saved - So you’ll know which file to restore. You can do this by typing:

bin/magento info:backups:list

It will display something like this

Showing backup files in /var/www/html/var/backups.
+------------------------------+-------------+
| Backup Filename              | Backup Type |
+------------------------------+-------------+
| 1544315558_media_vanilla.tgz | media       |
| 1550502745_media_example.tgz | media       |
+------------------------------+-------------+

To be continued. Waiting on answers from previous questions…

damianduffy · February 18, 2019, 3:53pm

Load the Frontend

Frontend loads as normal (I disabled maintenance mode manually a short while ago)

Login to the Backend*

Backend also loads normally - Nothing appears to be wrong.

Revisit the Web Setup Wizard*

Doesn’t load the normal Web Wizard screen but instead brings me back to the final step where I had left off. The option to rollback is still there. While the different links to Web Wizard sections are visible on left, none of them actual work. Essentially I’m stuck on this page with only the “rollback” option.

digitalstartup · February 18, 2019, 4:10pm

Gotcha. So, when you run any sort of updates Web Setup Wizard drops a hidden file in the var/ directory. Essentially a placeholder. I “believe” removing this file will tell Web Setup Wizard that it’s no-longer midway through an update.

If you run ls -la var/ from the magento root directory, do you have any files that begin with a “.” other than the ones I’m listing below (if so, what are they called)?

magento@DS-M23v:/var/www/html$ ls -la var/
drwxrwx---  2 magento  www-data 4096 Feb 18 15:40 backups
drwxrwsr-x 19 magento  www-data 4096 Feb 14 15:32 cache
drwxrwsr-x  3 www-data www-data 4096 Feb 14 17:27 composer_home
-rw-rw-r--  1 magento  www-data  126 Dec  9 00:05 .htaccess
drwxrwsr-x  2 www-data www-data 4096 Dec  9 00:41 log
drwxrwsr-x 19 www-data www-data 4096 Dec  9 14:04 page_cache
-rw-rw-r--  1 www-data www-data  246 Feb 17 18:53 resource_config.json
-rw-rw-r--  1 magento  www-data    5 Dec  9 00:41 .sample-data-state.flag
-rw-rw-r--  1 magento  www-data 6453 Feb 18 16:06 .setup_cronjob_status
drwxrwsr-x  2 www-data www-data 4096 Dec 27 05:04 tmp
-rw-r--r--  1 magento  www-data  148 Feb 18 16:06 .update_cronjob_status
drwxrwsr-x  3 www-data www-data 4096 Dec  9 00:41 view_preprocessed

Standard Hidden Files

.htaccess
.sample-data-state.flag
.setup_cronjob_status
.update_cronjob_status

EDIT: I think you might have an extra file called .update_in_progress. Try renaming it to something else and then reloading the Web Setup Wizard. For example, you could run the following from the Magento root directory:

mv var/.update_in_progress var/.tmp_update_in_progress

It should fool Web Setup Wizard that the file is deleted but without actually deleting the file in case you need to restore it.

damianduffy · February 18, 2019, 4:50pm

drwxrwx---  2 magento  www-data  4096 Feb 18 11:55 backups
drwxrwsr-x 19 magento  www-data  4096 Feb 18 11:48 cache
drwxrwsr-x  3 www-data www-data  4096 Jan 29 19:29 composer_home
-rw-rw-r--  1 www-data www-data  2296 Jan 29 19:44 composer.json
drwxr-s---  3 magento  www-data  4096 Feb  1 00:00 export
-rw-rw-r--  1 magento  www-data   126 Jan  4 17:19 .htaccess
drwxrwsr-x  3 www-data www-data  4096 Jan 30 00:00 log
-rw-rw-r--  1 magento  www-data    13 Feb 18 11:44 .maintenance.ip
drwxrwsr-x 19 www-data www-data  4096 Jan 10 05:46 page_cache
-rw-rw-r--  1 www-data www-data   246 Jan 28 14:17 resource_config.json
-rw-rw-r--  1 magento  www-data  6487 Feb 18 16:42 .setup_cronjob_status
drwxrwsr-x  2 www-data www-data  4096 Feb 18 11:49 tmp
-rw-rw-r--  1 www-data www-data   144 Feb 18 11:46 .type.json
-rw-r--r--  1 magento  www-data   148 Feb 18 16:42 .update_cronjob_status
-rw-r--r--  1 magento  www-data     0 Feb 18 11:55 .update_error.flag
-rw-rw-r--  1 www-data www-data     0 Feb 18 11:55 .update_queue.json
-rw-rw-r--  1 magento  www-data 27443 Feb 18 16:42 .update_status.txt
drwxrwsr-x  3 www-data www-data  4096 Feb 18 11:48 view_preprocessed

composer.json
.maintenance.ip
.type.json
.update_error.flag
.update_queue.json
.update_status.txt

.update_status.txt appears to be an output of the console log.
error.flag and queue.json are empty.

digitalstartup · February 18, 2019, 4:55pm

Try running the following 2 commands from the magento root directory as the magento user:

mv var/.update_error.flag var/.tmp_update_error.flag
mv var/.update_queue.json var/.tmp_update_queue.json

This will remove the flag that causes the Web Setup Wizard to stay stuck in this state.

Once you have confirmed this works, don’t forget to go back and delete those 2 temporary files that you made.

damianduffy · February 18, 2019, 5:07pm

Thanks Craig - that fixed it. Module is now showing as disabled.

I’m going to uninstall the module from extension manager and try to install the newer version from the CLI.

digitalstartup · February 18, 2019, 5:14pm

Awesome

It might also be worth investigating why the backups failed to begin with in a seperate post if you get round to it.