Elasticsearch doesn't start after run 'sudo chef-client' over knife ssh about elasticsearch HOT 9 CLOSED

Indeed, I can replicate the issue locally with a Vagrant node:

knife ssh name:elasticsearch* "sudo service elasticsearch start" -a cloud.public_ipv4 -x vagrant -i /Users/karmi/.vagrant.d/insecure_private_key -p 22

Nothing in the elasticsearch log to indicate it's starting/crashing/etc. On the other hand, running the command over raw SSH works as expected:

ssh elasticsearch-1 -F vagrant_ssh_config_elasticsearch "sudo service elasticsearch start"

Now, we are running lots of knife ssh in production, without this error. My bet is that something with the -x (--ssh-user) option is fishy with knife ssh. Try it with a setup which does not require you to specify SSH user and report back.

My suggestion is to close this issue, and open an issue at http://tickets.opscode.com, since the problem lies within Chef.

from elasticsearch.

Any news on this? Closing?

from elasticsearch.

I have test it more. If chef-client runs without sudo and -x param (as root), the problem is the same.

sudo knife ssh "name:elasticsearch*" "chef-client" -a ipaddress

Debug log:
194.123.86.10 [2012-11-12T15:19:54+01:00] INFO: Processing service[elasticsearch] action restart (elasticsearch::default line 45)
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] supports status, running
194.123.86.10 elasticsearch running with PID 30225
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] is running
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 0, action stop, priority 01
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 1, action stop, priority 01
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 2, action start, priority 02
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 3, action start, priority 02
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 4, action start, priority 02
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 5, action start, priority 02
194.123.86.10 [2012-11-12T15:19:54+01:00] DEBUG: service[elasticsearch] runlevel 6, action stop, priority 01
194.123.86.10 Stopping elasticsearch...
194.123.86.10 .
194.123.86.10
194.123.86.10 Starting elasticsearch...
194.123.86.10 [2012-11-12T15:19:55+01:00] INFO: service[elasticsearch] restarted

...but elasticsearch is not running

from elasticsearch.

Does the command run fine via regular SSH (see example above), or does it fail as well?

from elasticsearch.

Via regular ssh: ssh user@elasticsearch "sudo chef-client" it runs fine without any problem.

from elasticsearch.

Then I'm afraid the problem is with the knife command. As said, we're using that in production, though without passing attributes to knife. Please report the issue to Opscode Chef ticket system.

from elasticsearch.

I have verified that knife ssh name:elasticsearch-cookbook-test "sudo chef-client" and knife ssh name:elasticsearch-cookbook-test "sudo service elasticsearch restart" and then knife ssh name:elasticsearch-cookbook-test "sudo service elasticsearch status" works as expected on EC2 with Chef Server (10.16.6).

from elasticsearch.

Thanks! PR #91 actually fixed a problem with a Cassandra cookbook I'm using (that didn't use --background with start-stop-daemon). It wasn't working with knife ssh, but was working on the box or using ssh as described here.

from elasticsearch.

I ran into this same issue on ubuntu 14.04. I was able to work around it by issuing the command over ssh using sudo su -c. E.g.,:

knife ssh -xMY_USER MY_SEARCH "sudo su -c 'service elasticsearch start'"

from elasticsearch.