systemd unit file location

[mlewe]

This issue is a

• Bug Report
• Feature Request

Summary

ghost-cli creates systemd unit files in /lib/systemd/system/.
According to my understanding the directory /lib/systemd/system/ is intended for system-supplied unit files, i.e. those installed by the package manager of the distribution.
In contrast to that the directory /etc/systemd/system/ is intended for local machine-specific unit files (see here). I feel that the unit files installed by ghost-cli clearly fall in the local and machine-specific category and I was surprised to see them end up in /lib/systemd/system/.

This is more of a minor complaint than a proper bug report, but I think it would be good to follow best practices.

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

• OS: Ubuntu 16.04
• Node Version: v6.11.1
• Ghost-CLI Version: v1.0.1

[acburdine]

@mlewe Not sure if you know a better solution for this - I was testing putting the file in /etc/systemd/system and got a "too many links" error when I tried to run systemctl enable <ghost service>. It works if I put them in /lib/systemd/system though 😕

[ErisDS]

The document that @mlewe linked to doesn't even list /lib/systemd/system as an option, rather:

/etc/systemd/system/*
/run/systemd/system/*
/usr/lib/systemd/system/*

The ubuntu docs list /usr/lib/systemd/system and /lib/systemd/system.

I've seen reports that enable isn't working on Debian because /lib/systemd/system is the wrong place and it should be in /etc/, but the debian docs list 3 options with no clear distinctions other than the type of package that might live there:

/etc/systemd/system/*
/run/systemd/system/*
/lib/systemd/system/*

I haven't yet found any good, canonical (lol) resources for what is happening here, and what the best practices are, but I don't think changing this from lib to etc is the right thing for the default Ubuntu stack. Think this needs further investigation.

[mlewe]

I tried to reproduce that by creating a unit file example.service and linking it symbolically to
/lib/system/systemd/ as well as /etc/system/systemd/.
In both cases this leads to the error message
Failed to execute operation: Too many levels of symbolic links on xenial and
Failed to enable unit: Refusing to operate on linked unit file example.service on zesty.
Honestly I don't understand how ghost manages to run at all, since systemd seems to really dislike sym-links.

Regarding the comment on the Ubuntu documentation, here they list

/etc/systemd/system/*
/run/systemd/system/*
/lib/systemd/system/*

with /etc/systemd/system/* being intended for local configuration.
I agree that further investigation would be a good idea.

[acburdine]

Oops, didn't realize that the PR would close it 😬

[sesser]

I'm running into an issue with systemd and one of my ghost installs. Can't run ghost start because systemd service hasn't been installed. But when I run ghost setup systemd, it skips the process because it thinks it's already been setup!

I've removed any lingering *.service files related to the ghost instance, but it still complains. Any tips on this would be appreciated.

[sesser]

Disregard. After looking at .ghost-cli file, I set

"extension": {
    "systemd": false
}

and ghost setup systemd completed successfully.

[acburdine]

@hao-lee the point of this issue is to switch the location of the file to /etc/systemd/system 😄 there's just a couple of other things that need to be in place first in order for it to work.

[hao-lee]

After reading some document, I think Ghost create a symbolic link under /lib/systemd/system/ is reasonable. /etc/systemd/system/ contains the service that will be started at boot time and we can't put Ghost's unit file into it. If you run systemctl enable ghost_xxx-com.service to make Ghost start at boot time, you will see two symbolic link files will be created under /etc/systemd/system/.

[chasekafei]

Finally I find the reason HERE. It's a bug of systemd when using systemctl is-active or systemctl is-failed. Sometimes it returns unknown, not inactive.

They suggest to use
systemctl show ${this.systemdName} -p ActiveState which return ActiveState=inactive
instead of
systemctl is-active ${this.systemdName}
for stability promise for this command.

[chasekafei]

I replace line 88 in ghost-cli/extensions/systemd/systemd.js and everthing works fine now.

isRunning() {
  try {
      // execa.shellSync(`systemctl is-active ${this.systemdName}`);
      let isActive = execa.shellSync(`systemctl show ${this.systemdName} -p ActiveState`).stdout === 'ActiveState=active';
      return isActive;
  }
  ...
}

But I don't know whether can this works for everyone.

[github-actions]

Our bot has automatically marked this issue as stale because there has not been any activity here in some time. The issue will be closed soon if there are no further updates, however we ask that you do not post comments to keep the issue open if you are not actively working on a PR. We keep the issue list minimal so we can keep focus on the most pressing issues. Closed issues can always be reopened if a new contributor is found. Thank you for understanding 🙂