Failed to start Ghost systemd service

I’ve got some serious issues (well, my ghost instance has) and would really appreciate any help. Having solved a few issues with my blog some still remain. Here is my set up:

OS: Raspbian
Node: v14.15.3
Database: mariadb Server version: 10.1.47-MariaDB-0+deb9u1 Raspbian 9.11
Ghost-CLI version: 1.15.3
Ghost version: 3.40.2 (at /var/www/corballis.co.uk)

Output from ghost start

  • sudo systemctl is-active ghost_corballis-co-uk
  • sudo systemctl reset-failed ghost_corballis-co-uk
    :heavy_check_mark: Ensuring user is not logged in as ghost user
    :heavy_check_mark: Checking if logged in user is directory owner
    :heavy_check_mark: Checking current folder permissions
  • sudo systemctl is-active ghost_corballis-co-uk
    :heavy_check_mark: Validating config
    :heavy_check_mark: Checking folder permissions
    :heavy_check_mark: Checking file permissions
    :heavy_check_mark: Checking content folder ownership
    :heavy_check_mark: Checking memory availability
    :heavy_check_mark: Checking binary dependencies
  • sudo systemctl start ghost_corballis-co-uk
  • sudo systemctl stop ghost_corballis-co-uk
    :heavy_multiplication_x: Starting Ghost: corballis-co-uk
    A GhostError occurred.

Message: Could not communicate with Ghost
Suggestion: journalctl -u ghost_corballis-co-uk -n 50

Debug Information:
OS: Raspbian GNU/Linux, v9
Node Version: v14.15.3
Ghost Version: 3.40.2
Ghost-CLI Version: 1.15.3
Environment: production
Command: ‘ghost start’

Additional log info available in: /home/tc/.ghost/logs/ghost-cli-debug-2021-01-01T15_34_17_954Z.log

Try running ghost doctor to check your system for known issues.

ghost doctor returns same

sudo journalctl -u ghost_corballis-co-uk returns

Jan 01 16:07:30 corb-08-pi systemd[1]: Failed to start Ghost systemd service for blog: corballis-co-uk.
Jan 01 16:07:30 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Unit entered failed state.
Jan 01 16:07:30 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Failed with result ‘exit-code’.
Jan 01 16:29:17 corb-08-pi systemd[1]: Started Ghost systemd service for blog: corballis-co-uk.
Jan 01 16:29:17 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Main process exited, code=exited, status=203/EXEC
Jan 01 16:29:17 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Unit entered failed state.
Jan 01 16:29:17 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Failed with result ‘exit-code’.
Jan 01 16:29:18 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Service hold-off time over, scheduling restart.
Jan 01 16:29:18 corb-08-pi systemd[1]: Stopped Ghost systemd service for blog: corballis-co-uk.
Jan 01 16:29:18 corb-08-pi systemd[1]: Started Ghost systemd service for blog: corballis-co-uk.
Jan 01 16:29:18 corb-08-pi systemd[1]: ghost_corballis-co-uk.service: Main process exited, code=exited, status=203/EXEC

Because of the status=203/EXEC, I thought it could be a problem with the .service file. When I looked the ExecStart wasn’t pointing at the correct directory for either node or ghost so I changed it from

ExecStart=/usr/bin/node /usr/bin/ghost run

To

ExecStart=/usr/local/bin/node /usr/local/bin/ghost run

Why? Because when I ran whereis node it returned: node: /usr/local/bin/node. Same thing when I ran whereis ghost.

There is also the following error in the production log:
Can't connect to the bootstrap socket (localhost 8000) ECONNREFUSED.
But this appears to be related to the ExecStart line change that was needed, i.e. resolving the one should resolve the other.

Other things I have tried:

  • ghost install local that worked and produced a reachable development site on localhost:2368
  • Installing a brand new copy of ghost in a newly created directory. Same issues.

Now I’m literally at my wits end or, at least, the end of my knowledge and Google search is only throwing up that the ExecStart line in the service file should be changed, which I’ve already done but to no avail.

Can you try removing the bootstrap-socket config key from your config.production.json file and trying again?

So, I got it to work by opening up that port on ufw although I have now exposed an entirely different issue :frowning: which I think is related to node.js (express) performing a redirect instead of it being done by nginx.

You shouldn’t open the bootstrap socket or the listening port if you’re using nginx

Thanks. I’ll remove that line and see what happens.