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

SystemD unit is written to non-standard location #16046

Closed
fatmcgav opened this issue Jan 15, 2018 · 3 comments · Fixed by #83571
Closed

SystemD unit is written to non-standard location #16046

fatmcgav opened this issue Jan 15, 2018 · 3 comments · Fixed by #83571
Labels
Feature:Build Packaging Team:Operations Team label for Operations Team

Comments

@fatmcgav
Copy link

I have just installed Kibana 6.1 on a CentOS 7.3 box via Yum, and observed that the systemd unit has been installed to a non-standard location of /etc/systemd/system/.

Standard packaging practise is for systemd unit files to be installed to /lib/systemd/system/.

Also of relevance is #6579, as currently logs are spamming /var/log/messages, when they should really go into '/var/log/kibana'.

N.B: It appears that the install location was changed as part of #7276

Kibana version: 6.1.1
Elasticsearch version: 6.1.1
Server OS version: CentOS 7.3.1611
Original install method (e.g. download page, yum, from source, etc.): yum
Steps to reproduce:

  1. Install Kibana RPM
  2. Check systemd unit location:
$ systemctl status kibana |grep loaded
   Loaded: loaded (/etc/systemd/system/kibana.service; enabled; vendor preset: disabled)
@jbudz jbudz added the Team:Operations Team label for Operations Team label Jan 17, 2018
@prupert
Copy link

prupert commented Feb 6, 2018

+1

@swanandvg
Copy link

I am facing this issue after upgrading kibana from 6.7 to 7.0. Suggest me any way to start Kibana as it is in the production environment.

@GoneWacko
Copy link

This is actually pretty annoying because this prevents masking the service:

root@host:/# systemctl mask kibana
Failed to execute operation: Invalid argument

To mask the service, systemd attempts to symlink /etc/systemd/system/kibana.service to /dev/null. But my guess is, since /etc/systemd/system/kibana.service is not a symlink but a regular file, it fails.

Compare this to Elasticsearch, which correctly installs to /usr/lib/systemd/system/elasticsearch.service:

root@host:/# systemctl status elasticsearch
● elasticsearch.service - Elasticsearch
   Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: http://www.elastic.co

root@host:/# systemctl mask elasticsearch
Created symlink from /etc/systemd/system/elasticsearch.service to /dev/null.

root@host:/# systemctl status elasticsearch
● elasticsearch.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

jbudz added a commit to jbudz/kibana that referenced this issue Nov 17, 2020
Generally packages should install service files to
/usr/lib/systemd/system.  The current location is typically used for
services configured by the system maintainer.

Closes elastic#16046
Closes elastic#27768
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Build Packaging Team:Operations Team label for Operations Team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants