Searchindex:rebuild fails: Please help me understand the error

Infos:

  • Used Zammad version: 3.5.0, Release 1603788665.5a776fce.centos7
  • Used Zammad installation source: RPM from Repo
  • Operating system: CentOS 7.8.2003
  • Browser + version: Not relevant

Problem description

After an zammad update (yum update zammad) I wanted to recreate the index because I had the impression, that it was incomplete. When running zammad run rake searchindex:rebuild --trace I am now getting the following error trace, which I don’t understand:

[root]# zammad run rake searchindex:rebuild --trace
** Invoke searchindex:rebuild (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke searchindex:version_supported (first_time)
** Invoke environment 
** Execute searchindex:version_supported
** Execute searchindex:rebuild
** Execute searchindex:drop
drop indexes...done
** Execute searchindex:drop_pipeline
delete pipeline (pipeline)... done
** Execute searchindex:create
create indexes...done
** Execute searchindex:create_pipeline
create pipeline (pipeline)... rake aborted!
Unable to process put request to elasticsearch URL 'http://127.0.0.1:9200/_ingest/pipeline/zammad558842541452'. Check the response and payload for detailed information: 

Response:
#<UserAgent::Result:0x00005633f199c408 @success=false, @body="{\"error\":{\"root_cause\":[{\"type\":\"parse_exception\",\"reason\":\"No processor type exists with name [attachment]\",\"processor_type\":\"foreach\",\"suppressed\":[{\"type\":\"parse_exception\",\"reason\":\"No processor type exists with name [attachment]\",\"processor_type\":\"foreach\"}]}],\"type\":\"parse_exception\",\"reason\":\"No processor type exists with name [attachment]\",\"processor_type\":\"foreach\",\"suppressed\":[{\"type\":\"parse_exception\",\"reason\":\"No processor type exists with name [attachment]\",\"processor_type\":\"foreach\"}]},\"status\":400}", @data=nil, @code="400", @content_type=nil, @error="Client Error: #<Net::HTTPBadRequest 400 Bad Request readbody=true>!">

Payload:
{"description":"Extract zammad-attachment information from arrays","processors":[{"foreach":{"field":"article","processor":{"foreach":{"field":"_ingest._value.attachment","processor":{"attachment":{"target_field":"_ingest._value","field":"_ingest._value._content","ignore_failure":true,"ignore_missing":true}},"ignore_failure":true,"ignore_missing":true}},"ignore_failure":true,"ignore_missing":true}},{"foreach":{"field":"attachment","processor":{"attachment":{"target_field":"_ingest._value","field":"_ingest._value._content","ignore_failure":true,"ignore_missing":true}},"ignore_failure":true,"ignore_missing":true}}]}

Payload size: 0M
/opt/zammad/lib/search_index_backend.rb:895:in `make_request_and_validate'
/opt/zammad/lib/search_index_backend.rb:84:in `block (2 levels) in processors'
/opt/zammad/lib/search_index_backend.rb:68:in `each'
/opt/zammad/lib/search_index_backend.rb:68:in `block in processors'
/opt/zammad/lib/search_index_backend.rb:65:in `each'
/opt/zammad/lib/search_index_backend.rb:65:in `processors'
/opt/zammad/lib/tasks/search_index_es.rake:95:in `block (2 levels) in <main>'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `block in execute'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `each'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `execute'
/opt/zammad/lib/tasks/search_index_es.rake:67:in `block (2 levels) in <main>'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `block in execute'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `each'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `execute'
/opt/zammad/lib/tasks/search_index_es.rake:178:in `block (2 levels) in <main>'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `block in execute'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `each'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `execute'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:214:in `block in invoke_with_call_chain'
/opt/zammad/vendor/ruby-2.6.6/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:194:in `invoke_with_call_chain'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:183:in `invoke'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:160:in `invoke_task'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:116:in `each'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:116:in `block in top_level'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:125:in `run_with_threads'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:110:in `top_level'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:83:in `block in run'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:186:in `standard_exception_handling'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:80:in `run'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/exe/rake:27:in `<top (required)>'
/opt/zammad/vendor/bundle/ruby/2.6.0/bin/rake:23:in `load'
/opt/zammad/vendor/bundle/ruby/2.6.0/bin/rake:23:in `<top (required)>'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/cli/exec.rb:74:in `load'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/cli/exec.rb:74:in `kernel_load'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/cli/exec.rb:28:in `run'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/cli.rb:463:in `exec'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/cli.rb:27:in `dispatch'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/cli.rb:18:in `start'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/exe/bundle:30:in `block in <top (required)>'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/exe/bundle:22:in `<top (required)>'
/opt/zammad/bin/bundle:3:in `load'
/opt/zammad/bin/bundle:3:in `<main>'
Tasks: TOP => searchindex:rebuild
[roo]#

Any help or hint helping me understand what is going wrong in detail is highly appreciated.

Thanks

I found the solution in Rebuilding the searchindex ist not possible: No processor type exists with name [attachment].

It’s completely unclear when Elasticsearch’s ingest-attachment plugin got lost, but at least it seems that the index is being created w/o errors after having reinstalled it.

1 Like

Reinstalling the ingest-plugin is mandatory after every Elasticsearch-Update.
This is how ES works.

This usually doesn’t come to your attention if you update Zammad in the same process (and the Zammad package is updated after Elasticsearch). Our scripts handle that step for you in that case.

I am aware of that. But there hasn’t been any ES update, only a Zammad(-only) update. However it works now and since the whole operation happened in the frame of a complete service restore, this could have been a collateral effect :slight_smile: I’ll have a close eye on it when we update Zammad the next time.

If you’re running Zammad behind a proxy, you may have to tell ES about that.
That may be the reason why the Zammad scripts fail to reinstall the plugin automatically.

Good hint! That seems indeed to be the problem. However ES itself is already proxy enabled through /etc/elasticsearch/jvm.options.d/proxies.options and the proxy environment variables are globally set for all user profiles. I’ll have to check why these settings are not respected during the upgrade

1 Like

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