Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

command "ghost restart" doesn't work #575

Closed
heyauri opened this issue Dec 27, 2017 · 16 comments
Closed

command "ghost restart" doesn't work #575

heyauri opened this issue Dec 27, 2017 · 16 comments

Comments

@heyauri
Copy link

heyauri commented Dec 27, 2017

This issue is a

Bug Report

Summary

My VPS was rebooted by its supplier, and then I wanted to restart my ghost services.However, the command "ghost restart" doesn't work.

I have tried reinstall ghost-cli, but the error still existed.

Steps to Reproduce (for a bug report)

ghost restart

Technical details (will be automatically output by Ghost-CLI if an error occurs):

  • OS: CentOS 7
  • Node Version:6.11.2
  • Ghost-CLI Version: 1.4.1
  • Environment: production
  • Command: ghost restart

Here are the error log:

Debug Information:
    Node Version: v6.11.2
    Ghost-CLI Version: 1.4.1
    Environment: production
    Command: 'ghost restart'
An error occurred.
Message: 'failed
'

Stack: Error: failed

    at module.exports.sync (/usr/lib/node_modules/ghost-cli/node_modules/[email protected]@execa/index.js:303:26)
    at handleShell (/usr/lib/node_modules/ghost-cli/node_modules/[email protected]@execa/index.js:105:9)
    at Function.module.exports.shellSync (/usr/lib/node_modules/ghost-cli/node_modules/[email protected]@execa/index.js:312:43)
    at SystemdProcessManager.isRunning (/usr/lib/node_modules/ghost-cli/extensions/systemd/systemd.js:61:19)
    at Instance.running (/usr/lib/node_modules/ghost-cli/lib/instance.js:119:27)
    at RestartCommand.run (/usr/lib/node_modules/ghost-cli/lib/commands/restart.js:8:23)
    at precheck.then (/usr/lib/node_modules/ghost-cli/lib/command.js:206:52)
    at process._tickCallback (internal/process/next_tick.js:109:7)
    at Module.runMain (module.js:606:11)
    at run (bootstrap_node.js:389:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:504:3

Kate Note
Relies on better logging for systemd (issue TBD). We first need to improve logging to figure out what's going on.

@vikaspotluri123
Copy link
Member

Duplicate of #461 (it also contains temporary workaround info)

@jochenkirstaetter
Copy link

jochenkirstaetter commented Jan 2, 2018

Hi, unfortunately this is not a duplicate of #461

Today, I wanted to upgrade my site from 1.18.0 to latest 1.19.x but it failed due to migration steps. But that's a different problem... As suggested, I upgraded ghost-cli to latest and since then I cannot run any commands that are related to ghost sites anymore.

`Debug Information:
Node Version: v6.12.2
Ghost-CLI Version: 1.4.1
Environment: production
Command: 'ghost ls'
An error occurred.
Message: 'failed
'

Stack: Error: failed

at module.exports.sync (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:303:26)
at handleShell (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:105:9)
at Function.module.exports.shellSync (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:312:43)
at SystemdProcessManager.isRunning (/usr/lib/node_modules/ghost-cli/extensions/systemd/systemd.js:61:19)
at Instance.running (/usr/lib/node_modules/ghost-cli/lib/instance.js:119:27)
at Instance.summary (/usr/lib/node_modules/ghost-cli/lib/instance.js:177:19)
at instances.map (/usr/lib/node_modules/ghost-cli/lib/commands/ls.js:10:38)
at Array.map (native)
at LsCommand.run (/usr/lib/node_modules/ghost-cli/lib/commands/ls.js:9:32)
at precheck.then (/usr/lib/node_modules/ghost-cli/lib/command.js:206:52)
at process._tickCallback (internal/process/next_tick.js:109:7)
at Module.runMain (module.js:606:11)
at run (bootstrap_node.js:383:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:496:3`

The error is raised by node_module execa and not by ghost-cli's restart feature. Right now, I'm stuck with a situation that one site is still running and operational but a second Ghost site is down, and wouldn't start either.

The suggested workaround to extend .ghost-cli was already in place and doesn't resolve the problem either.

{ "cli-version": "1.4.1", "active-version": "1.18.0", "name": "example-com", "extension": { "systemd": true }, "running": "production" }

Regards, Jochen

@kirrg001
Copy link
Contributor

kirrg001 commented Jan 2, 2018

@jochenkirstaetter

Looks like it's failing at this line:

execa.shellSync(`systemctl is-active ${this.systemdName}`);

Is "example-com" the correct instance name?
What is the output of ls -la system/files/?

@jochenkirstaetter
Copy link

Hi @kirrg001

Sorry for confusion, it's not that problem. I changed the domain here in the issue description. The original instance name is located below system/files/ and matches the information below /lib/systemd/system/

After a number of attempts and reading other issues here in the repo I finally moved the base folder of the blog to another location, ie. /var/www/example, and therefore to another set of permissions. This fixed the migration issue with knex-migrator and the blog came back to life.

Was just a mess to amend the various configuration files of Ghost, nginx and systemd but well at last it's again operational. Interestingly, this wrong behaviour was introduced somewhere between 1.18.0 and following versions roughly. I started with Ghost 1.0.2 and upgraded since then regularly using the same folder structure and set of user permissions for 2 blogs.

Right now, I have another blog still running in its original location being stuck on 1.18.0 as the database migrations would fail. I'll have to move that base folder first in order to be able to upgrade.

It also didn't matter whether to use the knex-migrator coming with Ghost or using a globally installed version. Running the following statement knex-migrator-migrate --init --mgpath /.../current always failed due to Permission denied. First, I was struggling with the node environment additionally but even with NODE_ENV=production it wouldn't be allowed to run the migrations. Neither as blog owning user nor as ghost user.

As said, this used to work perfectly and smooth prior to Ghost versions > 1.18.0.

Eventually, something to consider for the documentation of self-hosting Ghost owners.

@acburdine
Copy link
Member

@jochenkirstaetter quick question - what OS are you running Ghost on?

From the looks of it the OP is running on Centos 7, which may or may not have a different systemd layout than Ubuntu 16 (which Ghost-CLI targets), so if you're running on Centos as well I can help troubleshoot this better :)

@jochenkirstaetter
Copy link

Hi @acburdine

Nope, it's not running on CentOS but Debian Jessie in my case.
Just today I upgraded one blog located below /var/www to 1.20.0 without anything but can't touch the other blog below another users' home directory although permission bits are okay for "other" access.

Cheers!

@deimidis
Copy link

deimidis commented Jan 18, 2018

I see Im having the same issue here. Trying to start the blog gave me the same error:

`Debug Information:
Node Version: v6.12.3
Ghost-CLI Version: 1.4.2
Environment: production
Command: 'ghost start'
An error occurred.
Message: 'unknown
'

Stack: Error: unknown

at module.exports.sync (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:303:26)
at handleShell (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:105:9)
at Function.module.exports.shellSync (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:312:43)
at SystemdProcessManager.isRunning (/usr/lib/node_modules/ghost-cli/extensions/systemd/systemd.js:61:19)
at Instance.running (/usr/lib/node_modules/ghost-cli/lib/instance.js:119:27)
at StartCommand.run (/usr/lib/node_modules/ghost-cli/lib/commands/start.js:28:22)
at precheck.then (/usr/lib/node_modules/ghost-cli/lib/command.js:206:52)
at process._tickCallback (internal/process/next_tick.js:109:7)
at Module.runMain (module.js:606:11)
at run (bootstrap_node.js:383:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:496:3

`
My ghost version is 1.20.0, and was upgrading this same system fine until a reboot from my VPS. I'm using debian jessie too.

If I install a new ghost instance works fine, unless it can "install" the service file and enable it, but ghost work. Also if I run 'ghost run' blogs works perfectly too

@aileen
Copy link
Member

aileen commented Jan 19, 2018

Closing this for now as it doesn't seems to appear on the recommended stack and therefore is not high priority to fix. Community PRs are always welcome!

@aileen aileen closed this as completed Jan 19, 2018
@kirrg001
Copy link
Contributor

Kate Note: Relies on better logging for systemd (issue TBD). We first need to improve logging to figure out what's going on.

The only problem of this issue is that the error handling is not good, this is a little independent from the stack. I would link this issue in #587.

@deimidis
Copy link

Finally found the problem. I was using ghost before ghost-cli and created special service files. With the new ghost version, those service files collide with the ones that ghost generate and basically that made it don't work

@jochenkirstaetter
Copy link

@AileenCGN - I don't think it's related to the supported stack but the documentation should be improved stating that the installation of Ghost shouldn't be located below a user's home directory, or in my case below another user's home directory.

/home/public/sites/ghost <== doesn't work, if your daily account isn't "public"
/var/www <== works

Eventually, I might find some spare time to verify this on the recommended stack of Ghost soon, and blog about it with more details.

More interestingly, why did it work between versions 1.0.2 and 1.18.0? But not any more on newer versions?

@ErisDS
Copy link
Member

ErisDS commented Jan 20, 2018

@jochenkirstaetter We very much welcome any support or contributions in terms of debugging other stacks or determining minor changes that might have caused issues with other stacks. The CLI team is not able to provide support for problems happening outside the recommended stack at present and we've recently updated our readme to reflect this.

The documentation does clearly state to only use /var/www/ in the install guide: https://docs.ghost.org/docs/install#section-create-a-new-folder. If there are other locations in the docs where you think this information should be included, please use the suggest edits button & we'll add your suggestions.

@AileenCGN one thing we can track as a potential change is to add a location check to ghost doctor so that the install warns when it's inside a user folder. Currently it only checks permissions of the current folder.

@cmivxx
Copy link

cmivxx commented Jan 26, 2018

I am having this exact same issue myself... Didn't matter what I did, the damn thing kept dying on me. Almost makes me want to swap back to WordPress while they get this sorted out.

However, just as I was about to give up, I frustratingly started restarting the server 3 times over and over, and it started to work again... dammit.

TLDR> continually rebooting the VPS seems to somehow resolve things. Sounds like a race condition to me.

@spruce
Copy link

spruce commented Jan 26, 2018

For whom it is interesting. Apparently the issue stems from sysctl returning unknown for a sym linked service when it is not running. I had the same problem (#575 (comment)) But I upgraded to a newer version and now it is working correctly.
@ErisDS Would you like a PR which more clearly outputs this possibility in the CLI?

@acburdine
Copy link
Member

@spruce if that indeed is the case, then I think #469 should solve this?

@spruce
Copy link

spruce commented Jan 26, 2018

@acburdine I suppose it would.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants