Stack: Error: Ghost process exited with code: 0

Enter ghost-install-dir and execute ghost restart then I got following message:

Debug Information:
    OS: Ubuntu, v16.04.6 LTS
    Node Version: v12.14.1
    Ghost Version: 3.3.0
    Ghost-CLI Version: 1.13.1
    Environment: production
    Command: 'ghost start --enable'
Message: Ghost process exited with code: 0
Stack: Error: Ghost process exited with code: 0
    at ChildProcess.<anonymous> (/home/dennis/.nvm/versions/node/v12.14.1/lib/node_modules/ghost-cli/lib/utils/local-process.js:56:24)
    at ChildProcess.emit (events.js:223:5)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)

The corresponding log file shows the same text.

Can not start the instance anyways. Website is down! Any ideas?

[yuraloginoff]

I had the same issue on Ubuntu 20.04.2 LTS x86_64.

How I fixed:

1. remove nodejs from Ubuntu Software (snapcraft.io)
2. install nvm (https://github.com/nvm-sh/nvm)
3. nvm install 14.17.1. v14.17.1 is the latest LTS at the moment (https://ghost.org/docs/faq/node-versions/)
4. npm install ghost-cli@latest -g
5. ghost install local

Hope that helps!

[acburdine]

@mrusme the reason you’re experiencing some oddities when running ghost run is because ghost run doesn’t do a number of the “pre-start” checks that the other commands do. One of those pre-start checks is determining which environment to run in - if ghost start detects that you’ve created a config.development.json but not a config.production.json, it will automatically switch to running in development mode. ghost run will default to running in production mode each time (saves a bit on memory consumption), so if you have a development setup and want to run things via ghost run, you’ll need to run ghost run -D instead to run it in development mode. This isn’t documented functionality, so apologies for the confusion.

Something we can probably improve on is our “defaults” for environment selection - if you’re on macOS or windows, we can probably safely assume you’re not running a production instance, and default to development mode. On linux, we’d keep production as the default mode.

As far as a solution to the underlying issue…I’m not 100% sure 😕 as you’ve noted, this issue has cropped up several times in different forms, and is tricky to pin down given the lack of debug information the CLI provides. That’s probably the first thing to fix, and once the CLI gives better error messaging, the underlying problem might be easier to see.