My Elasticsearch server is already running as a service. I can start and run it like so:
sudo service elasticsearch start
sudo service elasticsearch stop
However I would like to have it always running. Currently I need to start it manually on every system boot. I have already tried to register it as a deamon with the following commands:
sudo update-rc.d elasticsearch defaults
sudo update-rc.d elasticsearch defaults 95 10
I still need to start the Elasticsearch server manually. What do I need to do to run Elasticsearch as a daemon or start it at all on system startup? Since it is my local development environment, I would not need Elasticsearch as a daemon. I just need to start it on the startup of my system.
Not sure if you've found the answer or not (I'm assuming so), but for anyone who has not; you can use:
sudo systemctl enable elasticsearch.service
Related
I have a strange situation with a web service hosted on a debian instance, that sometimes stops, and does not restart automatically. However, when SSH-ing into the machine, the service seems to restart automatically.
I originally wanted the service to always be up and restart, could you help me figure out what's wrong ? I may have misunderstood how systemctl --user services are meant to run.
The service in question is a Rails application running with passenger standalone, but I believe the problem might just be a misconfiguration in the systemd file.
My systemd file
# .config/systemd/user/my_service.service
[Unit]
Description=passenger with rails server for my_service (production)
After=syslog.target network.target
[Service]
Type=forking
PrivateTmp=yes
WorkingDirectory=/websites/xxx/current
PIDFile=/websites/xxx/shared/tmp/pids/passenger.8080.pid
ExecStart=/home/outscale/.asdf/shims/bundle exec passenger start /websites/xxx/current
ExecStop=/home/outscale/.asdf/shims/bundle exec passenger stop /websites/xxx/current
MemoryAccounting=true
MemoryLimit=3584M
Restart=always
RestartSec=1
TimeoutStopSec=30
KillMode=mixed
StandardInput=null
SyslogIdentifier=%p
# Environment
Environment="RAILS_ENV=production"
Environment="NODE_ENV=production"
[Install]
WantedBy=default.target
I have copied this installed the service using
systemctl --user daemon-reload
systemctl --user enable my_service
Was I meant to use something else, like systemctl --global enable unit ? I want my service to run with the "outscale" user installing the service (otherwise my version manager asdf does not work as expected)
I found the solution to my problem there. I had misunderstood the behavior of the --user flag (VS using the User= property in the service file)
I was running under debian 11 and as stated in the mentioned answer, my service would not necessarily shut down after logging out of ssh, but only at some point (not clear if it happened when my service crashed for the first time or some sort of garbage collection)
And the service would boot up again magically when SSHing in the instance as a reaction to a user login and starting all the services.
So the fix was to reimplement the services using User= and without the --user flag to make it a globally available service.
I follow the first steps to install Flink.
I can start the cluster without any problem
$ start-cluster.sh
Starting cluster.
Starting standalonesession daemon on host DESKTOP-....
Starting taskexecutor daemon on host DESKTOP-....
But I don't get any status from
$ ps aux | grep flink
I can also not access the dashboard via localhost:8081.
There is an older post having these issues, but the solution didn't work for me, since the described conf files do no longer exist, apparently.
My JAVA_HOME is set as C:\Progra~1\Java\jdk1.8.0_311 to avoid issues with the space in Program Files.
Can you check the logs in the /logs folder? I'm suspecting that C:\Program Files\ could still cause issues because of the space there.
go to download Flink folder and try bash command
$./bin/start-cluster.sh --daemon bootstrap-server localhost:8081
and run code one more
$ ./bin/flink run examples/streaming/WordCount.jar
if you finished run above code which not issue, go to localhost:8081
This still seems to be problematic. I tried to run from Windows Subsystem for Linux (WSL).
I have the following versions: java 11.0.16 and flink 1.15.2.
sudo apt-get update
sudo apt install openjdk-11-jre-headless
export FLINK_HOME=/mnt/c/Projects/Apache/flink-1.15.2
I set the following in flink-conf.yaml
rest.port: 8081
rest.address: localhost
rest.bind-adress: 0.0.0.0
Whereby I changed the bind address for localhost to 0.0.0.0 this seems to have fixed the problem.
$FLINK_HOME/bin/start-cluster.sh
Now I can access the Flink Web Dashboard.
I'm trying to launch Neo4J graph database on AWS using their AIM image (enteprise 3.3.9)
However, the server fails to launch the instance automatically how it's supposed to.
When I try to relaunch it using
systemctl restart neo4j
It also fails.
When I do
systemctl cat neo4j
I find the /etc/neo4j/pre-neo4j.sh file, which is apparently launched on the instance's startup, which, in turn launches Neo4J (when it's supposed to work):
[Unit]
Description=Neo4j Graph Database
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/etc/neo4j/pre-neo4j.sh
Restart=on-failure
User=neo4j
Group=neo4j
Environment="NEO4J_CONF=/etc/neo4j" "NEO4J_HOME=/var/lib/neo4j"
LimitNOFILE=60000
TimeoutSec=120
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
So then I launch it manually via the bash script using the sudo prefix and then it starts up fine.
sudo /etc/neo4j/pre-neo4j.sh
The documentation on deploying Neo4J on an AWS server doesn't mention anything about permissions if you use their image. So what can be the problem?
I don't want to have manually launch the DB using the sudo — is it possible to resolve this problem by modifying the bash script itself?
..
The file /etc/neo4j/pre-neo4j.sh sets some environmental parameters and then launches neo4j via:
/usr/share/neo4j/bin/neo4j console
Based on the comments.
The solution was to use
journalctl -u neo4j
to inspect the logs associated with the failed start of neo4j. This enabled to identify the root cause, and subsequently, to fix the issue.
I had installed x-pack earlier and used it, and hosted Kibana through Nginx.
I yesterday uninstalled x-pack from both elasticsearch and kibana, via
sudo bin/elasticsearch-plugin remove x-pack
and
sudo bin/kibana-plugin remove x-pack
Now, when I try to start elastic, elastic is started, but Kibana does not start when I start kibana.
The Kibana.stdout log says,
{"type":"log","#timestamp":"2017-04-27T06:23:39Z","tags":["info","optimize"],"pid":49497,"message":"Optimizing and caching bundles for kibana, timelion and status_page. This may take a few minutes"}
And Kibana is never started.
The sudo service kibana status says it is running, but sudo netstat -ntlp, I can not find the port 5601.
It is never started. Why so ?
What can be the possible issue ?
Try deleting the kibana/optimize/bundles directory as well as the kibana/optimize/.babel-cache.json file and restarting Kibana. That will trigger a completely fresh rebuild of the Kibana source without x-pack.
Note: If you're using kibana as a system daemon, run the kibana process through the command line once to re-compile the optimize bundle before starting the daemon.
./usr/share/kibana/bin/kibana
Could anybody help me how to shutdown elasticSearch completely ! It starts automatically when system starts.
Yes, it should because you are initialing it in the config file, which fires every time the system starts.
To answer your question, I believe this answer should help.
It probably runs as a service. If it is on linux remove the service file, usually on /etc/init.d/elasticsearch
If it is on windows - there is a service.bat file on the installation/bin folder, you can uninstall using:
service.bat remove
If you are using Ubuntu 15.04+
systemctl disable elasticsearch
For Ubuntu < 15.04
To toggle a service from starting or stopping permanently you would need to:
echo manual | sudo tee /etc/init/SERVICE.override
where the stanza manual will stop Upstart from automatically loading the service on next boot. Any service with the .override ending will take precedence over the original service file. You will only be able to start the service manually afterwards. If you do not want this then simply delete the .override.
For more details, you may check this