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

[Packaging] systemd Service Unit Should Create a PID directory #7759

Closed
ralphct opened this issue Jul 15, 2016 · 5 comments
Closed

[Packaging] systemd Service Unit Should Create a PID directory #7759

ralphct opened this issue Jul 15, 2016 · 5 comments
Labels
bug Fixes for quality problems that affect the customer experience Feature:Build Packaging Team:Operations Team label for Operations Team

Comments

@ralphct
Copy link

ralphct commented Jul 15, 2016

Kibana version:
kibana-4.5.2-1.x86_64
Server OS version:
Centos 7
Browser version:
n/a
Browser OS version:
n/a
Original install method (e.g. download page, yum, from source, etc.):
yum
Description of the problem including expected versus actual behavior:
Kibana can (optionally, although maybe it should by default?) save out a PID file. The suggested location in the config file is /var/run/kibana.pid, but this is not writable by ordinary users. The usual solution is to create /var/run/kibana, chown it to the kibana user and then write the PID into it.

It's important to create this directory each time the service is started because on Redhat systems (and others) /var/run is emptied at system boot time, so any directories are lost.
Steps to reproduce:

  1. Enable PID file generation in /opt/kibana/config/kibana.yml and point it to /var/run/kibana.pid
  2. Restart kibana (systemctl restart kibana)
  3. Observe the PID file is not created (or not updated)

Errors in browser console (if relevant):
n/a
Provide logs and/or server output (if relevant):
n/a

A solution is to add two ExecStartPre lines to the Service Unit file, making it:

[Unit]
Description=no description given

[Service]
Type=simple
ExecStartPre=/bin/mkdir -p -m 0755 /var/run/kibana
ExecStartPre=/bin/chown kibana:kibana /var/run/kibana
User=kibana
Group=root
ExecStart=/opt/kibana/bin/kibana
Restart=always

[Install]
WantedBy=multi-user.target
@Bargs Bargs added bug Fixes for quality problems that affect the customer experience P2 labels Jul 15, 2016
@jbudz jbudz added the Team:Operations Team label for Operations Team label Nov 1, 2016
@epixa epixa removed the P2 label Apr 25, 2017
@fholzer
Copy link

fholzer commented Jun 24, 2019

There's actually a nicer way of doing this: simply add RuntimeDirectory=kibana (docs) in the [Service] section of the service file, then systemd will make sure the directory /var/run/kibana exists and the kibana user has write permission on it.

@tylersmalley
Copy link
Contributor

@jbudz is this still relevant?

@jbudz
Copy link
Member

jbudz commented Nov 3, 2020

Closed by #68262

@jbudz jbudz closed this as completed Nov 3, 2020
@archon810
Copy link

As per #68262 (comment), this still seems relevant.

@archon810
Copy link

I totally forgot about #7759 (comment) by @fholzer above and came up with this approach that works:

systemctl edit kibana.service 
[Service]
ExecStartPre=+/bin/sh -c 'touch /var/run/kibana.pid; chown kibana.kibana /var/run/kibana.pid'

This way, any updates to kibana won't actually overwrite the systemd service file, and the pidfile is created and chowned. But then I saw the RuntimeDirectory solution and tested it, and of course it also worked. 🤦‍♂️

Nevertheless, systemctl edit kibana.service is an important piece of the puzzle.

At least now I don't have to wait till kibana resolves this properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:Build Packaging Team:Operations Team label for Operations Team
Projects
None yet
Development

No branches or pull requests

7 participants