Curator_cli show_indices gives no output


(Jack Arnold) #1

Just trying out creator, so far I've installed the RPM on my elasticsearch node & tried showing my indices which doesn't give any output. I've tried the following commands;

[root@elastic01 ~]# curator_cli --host 127.0.0.1 --port 9200 show_indices --verbose --header
[root@elastic01 ~]# curator_cli --host 172.19.32.154 --port 9200 show_indices --verbose --header

Both of which silently exit. Apparently an expired x-pack licence can cause this issue. I have uninstalled the x-pack plugin from elasticsearch, but the issue still persists.

Elasticsearch is bound to 0.0.0.0, and curator_cli is running from the same machine elasticsearch is on, so both of those IP's should work. Any help appreciated.

Thanks,
Jack


(Aaron Mildenstein) #2

A full restart of the cluster is typically necessary to fully purge X-pack.

Also, debug logging is appropriate for troubleshooting here. You could add --loglevel DEBUG to see what it reveals. If that still shows nothing, a YAML --config might help, where you can add blacklist: [] to the logging block. This will show all elasticsearch and urllib3 log traffic, which is suppressed by default, as it is extremely verbose.


(Jack Arnold) #3

I've rebooted & tried again, here is the output from that command;

[root@elastic01 ~]# curator_cli --loglevel DEBUG --host 172.19.32.154 --port 9200 show_indices --verbose --header
2018-06-12 14:10:12,649 DEBUG     curator.cli_singletons.cli_action.show_indices          check_filters:117  Validating provided filters: [{'filtertype': 'none'}]
2018-06-12 14:10:12,649 DEBUG     curator.validators.SchemaCheck               __init__:26   Schema: <function Filters.<locals>.f at 0x7f7d6da62158>
2018-06-12 14:10:12,650 DEBUG     curator.validators.SchemaCheck               __init__:27   "filters" config: [{'filtertype': 'none'}]
2018-06-12 14:10:12,650 DEBUG     curator.validators.SchemaCheck               __init__:26   Schema: {'filtertype': Any(In(['age', 'alias', 'allocated', 'closed', 'count', 'forcemerged', 'ilm', 'kibana', 'none', 'opened', 'pattern', 'period', 'space', 'state']), msg="filtertype must be one of ['age', 'alias', 'allocated', 'closed', 'count', 'forcemerged', 'ilm', 'kibana', 'none', 'opened', 'pattern', 'period', 'space', 'state']")}
2018-06-12 14:10:12,650 DEBUG     curator.validators.SchemaCheck               __init__:27   "filter" config: {'filtertype': 'none'}
2018-06-12 14:10:12,651 DEBUG     curator.validators.filters                      f:48   Filter #0: {'filtertype': 'none'}
2018-06-12 14:10:12,651 DEBUG              curator.utils             get_client:803  kwargs = {'hosts': ['172.19.32.154'], 'port': 9200, 'url_prefix': '', 'aws_token': None, 'aws_sign_request': False, 'client_cert': None, 'use_ssl': False, 'http_auth': None, 'master_only': False, 'aws_key': None, 'ssl_no_validate': False, 'timeout': 30, 'certificate': None, 'client_key': None, 'aws_secret_key': None}
2018-06-12 14:10:12,656 DEBUG              curator.utils             get_client:880  Not using "requests_aws4auth" python module to connect.

I've got no errors there so i'm assuming it's connecting ok? Does the same thing with 127.0.0.1.

Running this gives no output.

curator --config /usr/share/curator/curator.yml /usr/share/curator/action.yml

The following is written to the log, my log level is set to 'DEBUG'

2018-06-12 14:29:01,901 DEBUG                curator.cli                    run:108  Client and logging options validated.
2018-06-12 14:29:01,901 DEBUG                curator.cli                    run:112  default_timeout = 30
2018-06-12 14:29:01,901 DEBUG                curator.cli                    run:116  action_file: /usr/share/curator/action.yml

Any ideas?


(Aaron Mildenstein) #4

Let me process this in reverse order.

Not progressing past action_file: /usr/share/curator/action.yml indicates a YAML parsing error. Something is probably improperly indented.

Not progressing past Not using "requests_aws4auth" python module to connect. indicates that Curator was unable to establish a client connection to the indicated node. This can further be tested by running: curl http://172.19.32.154:9200 (or 127.0.0.1) and seeing the output at the command-line.


(Jack Arnold) #5

Just ran the curl command, it wouldn't connect either. Checking the service i'm getting the following;

elasticsearch dead but subsys locked

Not sure why, it was up and running this morning, I was using kibana. Very strange. It's only stopped working since the reboot.

I've tried restarting the service, deleting the /var/lock/subsys/elasticsearch file, and rebooting the server, still with the same issue.


(Aaron Mildenstein) #6

That's an entirely different issue. Not sure how you hit that, but I've never seen it before.


(Jack Arnold) #7

It's only cropped up following the reboot after removing x-pack - It was working this morning.

Going to try rebooting again and see if I can get this fixed.


(Jack Arnold) #8

Well, following a reboot, elasticsearch and curator are now working.

This is really weird - I keep having issues where there have been no config changes & part of my stack breaks, with no apparent causes. Rebooting only sometimes resolves the issues, as I rebooted earlier and the error persisted. Really strange.


(system) #9

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