-
-
Notifications
You must be signed in to change notification settings - Fork 599
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
Elasticsearch tarball install fails to start under systemd #585
Comments
Relevant info regarding package install taking care of this: elastic/elasticsearch#21507 |
Hi @iancward -- thanks for the heads up! We're actually following the upstream packaging as much as possible. Looks like you've found that as well ^. We'll update our files based on the latest from upstream as soon as they are released. I'll leave this open to remind us to do so 👍 |
Sorry to throw a likely newbie question into a possibly only partially related thread. I'm trying to set this up using the tarball install, for an openSUSE build that includes both init.d and systemd framework. By default it appears to be trying to install an init script, which fails, and in any case I'd like to use systemd. I can't figure out a working syntax for the elasticsearch_service part of my wrapper that will configure the service under systemd. I've been reading every part of the cookbook and crawling the intertubes for two days, found some references to specifying my own init script, but no luck on how to force a systemd install or specify a services file (looks like the /templates/default/systemd_unit.erb would work OK in any case). I'd be grateful for any help including an RTFM if you'll just send me a link to the M I need to FR. Randy |
Hi @randyrue -- the deb and rpm packages install both, and this cookbook reproduces that behavior. As far as actually starting or stopping Elasticsearch with a specific one -- this cookbook relies on Chef to determine what init system to use. What version of openSUSE are we talking about? I could compare and see what behavior I see... |
Hi Martin - openSUSE Leap 42.2. I've inherited this effort from someone who previously found a workaround by temporarily renaming /etc/init.d and then restoring it after the elasticsearch_service call. I'm thinking it was meant to be a quick hack and now I'm trying to do it right. ERROR: elasticsearch_service[elasticsearch] (scharp_base_server::elasticsearch line 70) had an error: Chef::Exceptions::FileNotFound: template[/etc/init.d/elasticsearch] (/var/chef/cache/cookbooks/elasticsearch/libraries/provider_service.rb line 32) had an error: Chef::Exceptions::FileNotFound: Cookbook 'elasticsearch' (3.0.5) does not contain a file at any of these locations: |
Hi folks -- @randyrue please try the v3.3.0 release, and set @iancward still going to leave this open -- it looks like we need to do some of the same
|
Using 3.3.0 and my service section now reads: elasticsearch_service 'elasticsearch' do Do I have that syntax right? Still fails with: This cookbook does contain: ['templates/default/elasticsearch.in.sh.erb','templates/default/elasticsearch.yml.erb','templates/amazon/initscript.erb','templates/default/jvm_options.erb','templates/debian/initscript.erb','templates/default/log4j2.properties.erb','templates/redhat/initscript.erb','templates/centos/initscript.erb','templates/default/systemd_unit.erb','templates/ubuntu/initscript.erb','templates/oracle/initscript.erb'] |
Hi @randyrue -- no, the syntax |
Still no love, sorry... Removed the ticks and still get:
Running handlers: This cookbook does contain: ['templates/debian/initscript.erb','templates/centos/initscript.erb','templates/amazon/initscript.erb','templates/oracle/initscript.erb','templates/default/jvm_options.erb','templates/default/log4j2.properties.erb','templates/default/systemd_unit.erb','templates/default/elasticsearch.yml.erb','templates/redhat/initscript.erb','templates/ubuntu/initscript.erb','templates/default/elasticsearch.in.sh.erb'] |
Hi @randyrue -- that output shows you're still passing a string (see the |
I swear that's what I had :) I had removed the line and replaced our 'mv /etc/init.d' workaround. When I added "init_source nil" to the service section, and disabled the mv hack, all appears to be well. Thanks! |
Hi Again, Found a new issue but still within the area of systemd, don't know if it warrants a new issue or if it's appropriate to put it here. ES fails to start because it's trying to create PID file in /var/run/elasticsearch. But adding some lines to my recipe to create that subdir is no good, as later OS's are using tmpfs for /var/run (any changes are lost on reboot). Added a 'path.pid' => '/var/run', line to the configuration entries for my configuration chunk, and I can see a matching entry in my resulting /etc/elasticsearch/elasticsearch.yml. But the service file created for systemd still has a flat entry calling for /var/run/elasticsearch/. Looks like the template in the code also uses a flat entry for that, no substitution. What are my options? Rip out the tmpfs /var/run and mount it "real?" (yuck) Let me know. And let me know if you want me to delete this and repost as new... More to report after some progress: |
After some flailing the less than ideal workaround is to add a "file" entry in the recipe that creates /usr/lib/tmpfiles.d/elasticsearch.conf, containing one line: d /run/elasticsearch 0777 - - - - Note that the resulting subdir /var/run/elasticsearch is owned by root as our elasticsearch user exists in our ldap so the elasticsearch_user call in the recipe fails, and systemd-tmpfile fails to create the subdir if I specify elasticsearch as the owner. Instead I'm giving it 777 permisions (bleah), which are corrected the first time chef-client runs. good enough for now |
Hi @randyrue -- please open separate issues for your other questions/follow ups. |
Closing this issue since I pulled down the latest scripts from the latest packaging earlier this week. |
We used this cookbook to deploy Elasticsearch 5.3.0 via a tarball on RHEL7, and it deploys both a SysV (which sets
vm.max_map_count
) startup script and a systemd unit file (which doesn't setvm.max_map_count
). When Chef goes to start the service, the service claimsvm.maxmap_count
is too low and it fails to start.If I run
/sbin/service elasticsearch start
, the command gets redirected to systemctl (part of systemd) and the process fails to start. However, if I explicitly run/etc/init.d/elasticsearch start
, the process will start, as that script usessysctl
to setvm.max_map_count
.I've been trying to find a way to set
vm.max_map_count
via systemd and have not found anything. This cookbook might need to set themax_map_count
by some other means before it tries to start the service.The text was updated successfully, but these errors were encountered: