Deploy fail when invoke 'wp core is-installed' command

Hello,
When I’m deploying website with trellis deploy production example.com, I’m figuring this issue (deploy is ok on staging):

TASK [deploy : Invoke 'wp core is-installed' command] **************************
fatal: [ovh_production]: FAILED! => {"changed": false, "cmd": ["wp", "core", "is-installed", "--skip-plugins", "--skip-themes"], "delta": "0:00:00.160609", "end": "2024-01-11 11:09:58.712055", "failed_when_result": true, "msg": "non-zero return code", "rc": 255, "start": "2024-01-11 11:09:58.551446", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

The local situation:
trellis 1.21.0
trellis-cli 1.11.1
ansible core 2.16.0
python 3.12.0

The production (and staging) situation:
wp-cli: 2.8.0
php 8.1.26

I have several sites configured in trellis, each have staging and production in the same configuration. But only one site fail on deploy on production.

When I ssh to debug in production, I get this:


I don’t understand what happening, problem is the 255 exit code in folder not completely released as current.

Anyone have something for me to help?

Thank you all and wish a happy new year everyone!

1 Like

This could be the same issue as this one:

This could also help with finding the underlying error:
https://discourse.roots.io/t/wordpress-6-0-update-deploy-failed/23225/43?u=strarsis

Thank you for your response but it seem to be different.

As described in first solution I tried to change my config file using getenv() instead of env() but nothing changed as other websites could be deployed while using env().

Also, no errors reported in those files:

  • /var/log/php8.1-fpm.log
  • /var/log/auth.log
    even in
  • /var/log/kern.log
  • /var/log/nginx/error.log
  • /srv/www/example.com/logs/error.log

I re-provisionned the server but nothing is changing. Other websites on that trellis server are ok but not that one. Always falling here:

TASK [deploy : Invoke 'wp core is-installed' command] **************************
fatal: [ovh_production]: FAILED! => {"changed": false, "cmd": ["wp", "core", "is-installed", "--skip-plugins", "--skip-themes"], "delta": "0:00:00.161847", "end": "2024-01-12 14:14:27.688688", "failed_when_result": true, "msg": "non-zero return code", "rc": 255, "start": "2024-01-12 14:14:27.526841", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

I really don’t know what it could happened… totally lost.

For some quick and dirty debugging (deploy to staging Trellis in all of these approaches, as those are invasive):

  1. Empty the plugin folder (e.g. my renaming it/replacing with an empty directory) and re-invoke wp core is-installed – does it work now?
  2. Use a default theme for that site.
  3. Sprinkle some echo 'test'; exit; into the different Bedrock site and WordPress core files and see whether they appear when invoking wp core is-installed.
  4. Enable debugging and step through each and every line while wp core is-installed is running.

The wp core is-installed command is very simple and uses is_blog_installed() as first check:

I tried to remove plugins or theme but nothing changed.

When I modify web/wp/index.php and put echo 'test'; exit; on the first line, nothing change…

I realized if I do wp core is-installed --debug in a old release folder or current, I get this:


But if I run the same command from the last not released folder, I get:

So it seem to failed here: Debug (commands): Adding command: action-scheduler (0.469s)

I’m trying to investigate this way

1 Like

The weirdest thing is when I deploy to staging, I’m syncing db and files from production with the Sync script @ben made and everything goes right.
I’m stuck, if someone know something, he should tell it! :smiling_face_with_tear:

:thinking: The issue (and subsequent fix) could be caused either by a configuration issue (stored in database) or some cached (acorn) in uploads directory that was also transferred during sync.

I’m not using Acorn.

Nothing transferred by the sync process create issue. When I deploy to staging it’s a success even syncing datas (files and DB) from the production server.

The servers configurations are exactly the same (PHP, WP-CLI, MariaDB… ) and provisioning the servers are ok too…

Does the transfer script also flush the cache?

My Macbook was broken since 2 days… But I’m finally back!

Which cache? Because to flush it, WP Cli need to work but it doesn’t… It works only in “current” folder but not in the new generated release folder.

Good point! But would not the database import also involve wp CLI, and that worked, as the transfer script successfully transferred database.

The Sync Script is working with the “current” folder. Not in the “release folder” the Trellis deploy playbook create.
Problem is happening on deploy at this task: [deploy : Invoke 'wp core is-installed' command] in the “release folder”

I am actually having this same issue.

I have a staging environment and production environment both on digital ocean and I am able to provision and deploy to staging just fine.

When I attempt to deploy to production, I get this wp core is-installed problem and when I attempt to provision production, I get this:

TASK [mariadb : Set root user password] ****************************************

This has been an issue for a few months now but I am just coming back around to it again this week. Not sure what to do about it.

When you invoke wp core is-installed inside the affected release folder, what exit code do you get (echo $? for printing the exist code of last command)?
Any PHP related messages printed to terminal? (Edit: PHP CLI config is separate from PHP-FPM server config, so error reporting should be already enabled).

Hello.

This is the initial error I receive:

PHP Fatal error:  Uncaught Dotenv\Exception\InvalidPathException: Unable to read any of the environment file(s) at [/srv/www/project.com/releases/20240125035828/.env]. in /srv/www/project.com/releases/20240125035828/vendor/vlucas/phpdotenv/src/Store/FileStore.php:57
Stack trace:
#0 /srv/www/project.com/releases/20240125035828/vendor/vlucas/phpdotenv/src/Dotenv.php(157): Dotenv\Store\FileStore->read()
#1 /srv/www/project.com/releases/20240125035828/config/application.php(33): Dotenv\Dotenv->load()
#2 phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1197) : eval()'d code(7): require_once('/srv/www/project...')
#3 phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1197): eval()
#4 phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1158): WP_CLI\Runner->load_wordpress()
#5 phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#6 phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(74): WP_CLI\Bootstrap\LaunchRunner->process()
#7 phar in /srv/www/project.com/releases/20240125035828/vendor/vlucas/phpdotenv/src/Store/FileStore.php on line 57

The exit code I get after running echo $? is 127

So there is no .env file in that release, hence the Bedrock site cannot run.
Copy an existing .env from current/ / a working release directory,
and try the wp core is-installed command in the directory of affected release again, does it work then?

Thanks, I will likely give it a shot tomorrow or over the weekend.

I was curious so I checked the production server and the .env file does exist in the latest release. I viewed the file and everything looks correct within it for production.

Where it was similar to the initial topic issue? If it’s not you should, create an other topic to get the ability to mark it solved when it will be done. That help other to don’t read two topic in one and save time. And by the way, my thread :smiley:

1 Like

If a new deploy is suddenly failing, the first thing I’d check is what changed between releases. What’s different in your git repo between the failing release and the last working release?

You can reference GIT_SHA from the .env file in your release directory to get the specific git reference that was used to deploy