Starting and stopping elasticsearch without root privileges in linux centOS


#1

Hi.
I want to install the ELK stack in a production machine that has CentOS on it. It dosen't have internet connection and I don't have root privileges .
I can easly provid an install the ELK stack from manually deliver rpms.
Starting and quitting is a different story. The manual for elasticsearch (and any other part of ELK) says that systemctl needs to be used, but centos dosen't allow for systemctl use it you are not the root user.
Is there an elegant way to start and stop the ELK start programs when you are not the root user?


(Attila Boncok) #2

Download the tarball and run Elasticseach with the binary.

{ES_install_root}/bin/elasticsearch -d

If you want to save the PID to a file:

{ES_install_root}/bin/elasticsearch -d -p {file_path}

Not really a nice way to do it on a production environment, but it works.

If you can ask the sysadmin, ask him to give you sudo right to control the elasticsearch service.


#3

thanks, but starting the process is the easy part. Can you think of a way to stop elegantly without using systemctl?


(Attila Boncok) #4

You start ES with systemctl but can't stop with it? If so, ask your sysadmin to give sudo right for the stop command too.
If not, how do you start ES?


#5

I start by simply running ./elasticsearch (or kibana, or logstash) from bash script, without using systemctl.


(Attila Boncok) #6

You can then just use kill to stop the process. You can also use a bash script if it's more convenient.
Make ES create a pid file when starting.

Then just kill the process.

kill $(cat {file_path})

#7

I thought about it, but doesn't this method make an abropt exit from elastic, and will cause errors?
How exiting with 'kill' effects elastic processes?
Is it equivalent to what happens when I use systemctl stop elastic/kibana/logstash?


(Attila Boncok) #8

The word kill does sound dramatic, but without options it just tells the process to quit normally. It won't do any harm.

kill -KILL would terminate the process instantly, leaving no chance for it to do a safe shutdown. Avoid it unless the process isn't reacting to anything, which is typical eg. after an out of memory exception.


(system) #9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.