Make ghost run be responsible for outputting running environment

[acburdine]

There have been several issues raised recently (#461, #449, #431, #430) where the CLI loses track of running blog state when using systemd. The root cause of this is related to how the CLI keeps track of instance running environment.

Currently, ghost start starts Ghost using the configured process manager for the particular environment, and after it has been started sticks a value into the .ghost-cli file at the root of the install that notes what environment Ghost is currently running in. This value is used by the CLI as the source of truth about whether or not a blog is running. If the value does not exist in the .ghost-cli file the blog is assumed to not be running; if it exists, the configured process manager for the running environment is queried to ensure that the blog is actually still running. This approach has issues with systemd in a couple of cases:

• you run ghost stop, then reboot the server. Because the systemd service has been configured to start on boot, the ghost instance is started on boot but no value is output to the .ghost-cli file because ghost was started automatically, not using ghost start
• you use systemctl start/stop ghost_<servicename> to start/stop Ghost rather than ghost start/ghost stop. This causes the same issue of the running environment not being tracked.

To fix this, we need to give responsibility for updating running environment to the ghost run command (which both the local process manager and the systemd process manager use under the hood). However, we can't make ghost run modify the .ghost-cli file as ghost start does right now - because systemd runs ghost run as the ghost system user, it won't have permissions to edit that file. Instead, ghost run will output a .environment file into the content directory of the ghost install (which the ghost system user does have write access to) and then the CLI will use that file to determine what environment the CLI is currently running in.

[gcochard]

Why doesn't it query systemctl if it doesn't see the environment in .ghost-cli? This seems backwards to me. I'd prefer if it would query all known instances, even if that were a bit slower.

[acburdine]

@gcochard that's a valid point - however it's not possible given the way Ghost-CLI works with running environments at the moment.

Ghost-CLI is set up so that you can extend it and use a different process manager as long as there's an extension you've installed for it (e.g. pm2 or supervisor). The particular process manager you are going to use is determined during ghost setup, and is stored in the config file for that particular environment (e.g. config.production.json, config.development.json). The reason for this is mainly because you could, in theory, set up Ghost using Ghost-CLI to run in both development & production mode. Not at the same time of course, but one issue that presents with Systemd is that you can only specify one environment to run in the service file (because it's passed in using the NODE_ENV environment variable, which is hardcoded into the service file). So essentially, if you ran Ghost-CLI in development mode after setting it up with systemd, you'd end up running ghost in production mode despite thinking you'd started it in development.

So, Ghost needs to know the running environment in order to determine what process manager to query - and that is ultimately why we can't just query systemd - as nice as that would be to do.

[kirrg001]

So, Ghost needs to know the running environment in order to determine what process manager to query - and that is ultimately why we can't just query systemd - as nice as that would be to do.

I don't understand that. The running environment is default production if config.production.json exists. Development env has to be either specified via env param or the config.development.json contains process: local (or any other extension). I am confused 🙂

[acburdine]

I don't understand that. The running environment is default production if config.production.json exists. Development env has to be either specified via env param or the config.development.json contains process: local (or any other extension). I am confused

Hmm....that's not a bad point - however if someone started a Ghost blog in production mode (ghost start) and also had a development config, then ran ghost start -D, ghost wouldn't know to check whether or not the blog is already running in production. Might be a bit of an edge case, but still worth considering I think.

[kirrg001]

then ran ghost start -D, ghost wouldn't know to check whether or not the blog is already running in production. Might be a bit of an edge case, but still worth considering I think.

I think this can be covered be ensuring that the ports must be different?
If you use -D and no development config exists, simply use different port.
If you use -D and development config exists and it's the same than the production config, force a modification or similar.

Sounds like to me asking the configured extension can work as a possible solution here?
This issue is definitely high priority.

will output a .environment file into the content directory of the ghost install (which the ghost system user does have write access to) and then the CLI will use that file to determine what environment the CLI is currently running in.

BTW: This sounds a bit too hacky. The content folder should not be used for CLI files.

[spruce]

I just stumbled over this problem myself. Why is there a need to run the same folder / instance in different config envs? Could you explain why there is a need for it?
As I understand https://12factor.net/config it should only be one config without a deployment target name in it. So it only should be config.json and everything needed in there (like process manager). If I want the same blog (backing db) under another URL I have to have another folder. Only problem would be the backing content folder which could be symlinked in if needed.

If nothing too big speaks against only one config I'd like it more as it greatly simplifies everything.