An unexpected error occurred! {:error=>#<ArgumentError: wrong number of arguments (given 3, expected 1..2)> #13777
Comments
|
At first glance, this looks like either a bug in upstream Sinatra, related to sinatra/sinatra#1670 or in how keyword arguments are un-splatted and re-splatted in Jruby. I will take a further look at this in the morning. Are you doing anything special with the |
|
We are experiencing a similar issue, with no 8.0 upgrade. Everything was running earlier today, and we pushed a change to the SQL query used for our JDBC input triggering a Docker re-build, and now are getting this same error from the LogStash runner as the root issue. Version: Logstash 7.16.2 |
|
@yaauie We don't have any real config in the logstash.yml only the http.host has been set. |
|
@Will-Johns same backtrace? Would you mind sharing your |
|
Workaround: set either |
|
@yaauie Yeah I can get it still if you want, but it is the same back trace ( Sinatra 2.2.0 ). I think our problem may actually be a vendor bundling one. I just checked and the service that reported it is using the OpenSearch tarball of LogStash ( from the Ingest Tools section of this page ) so I'll follow up there instead. Just knowing the root cause is great though and saved me a big headache, so thank you @yaauie |
|
setting |
|
@skywalkerisnull what else are you doing in your setup & preconfigurstion? Logstash 8.0.0 shipped with Sinatra 2.1.0, not the 2.2.0 in your backtrace -> https://github.com/elastic/logstash/tree/v8.0.0/Gemfile.jruby-2.5.lock.release#L743 |
|
@yaauie I run a Here are the relevant parts:
version: '3.2'
services:
logstash:
build:
context: logstash/
args:
ELK_VERSION: $ELK_VERSION
volumes:
- type: bind
source: ./logstash/config/logstash.yml
target: /usr/share/logstash/config/logstash.yml
read_only: true
- type: bind
source: ./logstash/pipeline
target: /usr/share/logstash/pipeline
read_only: true
ports:
- "5044:5044"
- "5000:5000/tcp"
- "5000:5000/udp"
- "9600:9600"
# HTTP
- "8080:8080/tcp"
- "8080:8080/udp"
# SNMP
- "161:161"
- "162:162"
# Syslog
- "514:514/tcp"
- "514:514/udp"
environment:
LS_JAVA_OPTS: "-Xmx4096m -Xms4096m"
restart: always
networks:
- elk
depends_on:
- elasticsearch
ARG ELK_VERSION
# https://www.docker.elastic.co/
FROM docker.elastic.co/logstash/logstash:${ELK_VERSION}
# Add your logstash plugins setup here
RUN logstash-plugin install \
logstash-filter-json \
logstash-filter-bytes \
logstash-filter-extractnumbers \
logstash-input-http_poller \
logstash-input-http \
logstash-input-redis \
logstash-input-imap \
logstash-input-tcp \
logstash-input-udp \
logstash-input-redis \
logstash-input-syslog \
logstash-input-snmp
ELK_VERSION=8.0.0
---
## Default Logstash configuration from Logstash base image.
## https://github.com/elastic/logstash/blob/master/docker/data/logstash/config/logstash-full.yml
#
http:
host: "0.0.0.0"
# enabled: false
api.enabled: false
xpack.monitoring.elasticsearch.hosts: [ "http://elasticsearch:9200" ]
|
|
I would imagine that the invocation of It appears that all of the plugins referenced in your pipeline are already bundled with Logstash. Is there a particular reason why you are re-installing them and a variety of others? |
|
@yaauie That seems to line up with what I'm experiencing. I switched to trying to use the Elastic provided tarball for Logstash 7.16.2 and ran into the same issue after running Just came back to report the update. Also, for context we are using the tarball setup, because the way our deployment is setup it's very convenient for us to use the same Dockerfile for a Python web application ( the base image ), and the LogStash runner. |
|
I have commented out all of the installs and it now seems to be running for the past 5 minutes. I was not aware that it shipped with the majority. Or potentially, when we started using it, there was an issue with the inbuilt version and we had to upgrade (I can't recall what the reason was from a few years back) |
|
Great. We will probably need to pin the Sinatra dependency, and to chase down the issue upstream before unpinning. I'll also file a separate issue or follow up on the plugin manager updating irrelevant gems, which I don't think it should be doing. |
|
Running into the same issue here — Sinatra v2.2.0 looks to be getting updated when installing a plugin using To resolve, i've pinned the version of sinatra to ~> 2.1.0, which avoids the package getting updated to v2.2.0 when installing a new plugin... I've added the following to my docker-entrypoint script prior to the plugin installation... |
|
@matthew-muscat do you know how to fix it if it was already upgraded? Running Just cleaning the whole [EDIT] just changing the version in the |
|
Thank you @matthew-muscat - that's actually the fix that works for me. I use logstash within docker container. I added @matthew-muscat 2 lines before ....
RUN sed --in-place "s/gem.add_runtime_dependency \"sinatra\", '~> 2'/gem.add_runtime_dependency \"sinatra\", '~> 2.1.0'/g" /usr/share/logstash/logstash-core/logstash-core.gemspec
RUN /usr/share/logstash/bin/ruby -S /usr/share/logstash/vendor/bundle/jruby/2.5.0/bin/bundle install
RUN logstash-plugin install .....The code changes the logstash-core.gemspec - it replaces |
|
The previous locking will do but it's safer to restore all sinatra related changes directly in the Gemfile.lock : Safe this patch into a sinatra.patch file: diff --git Gemfile.lock Gemfile.lock
index 96b42c8..289508d 100644
--- Gemfile.lock
+++ Gemfile.lock
@@ -709,7 +709,7 @@ GEM
nio4r (~> 2.0)
racc (1.5.2-java)
rack (2.2.3)
- rack-protection (2.2.0)
+ rack-protection (2.1.0)
rack
rack-test (1.1.0)
rack (>= 1.0, < 3)
@@ -744,10 +744,10 @@ GEM
concurrent-ruby (~> 1.0)
sequel (5.52.0)
simple_oauth (0.3.1)
- sinatra (2.2.0)
+ sinatra (2.1.0)
mustermann (~> 1.0)
rack (~> 2.2)
- rack-protection (= 2.2.0)
+ rack-protection (= 2.1.0)
tilt (~> 2.0)
snappy (0.0.12-java)
snappy-jars (~> 1.1.0)
One will need to remember to restore Sinatra (until 7.17.1 and 8.0.1 are released #13784), optionally one could also avoid bumping into the next time using:
p.s. Please note that this issue also affects LS 7.17 and likely older as well (e.g. when installing a plugin). |
|
Sinatra claims to follow Semantic Versioning, so the 2.2.0 minor release should be backwards compatible. If it is not, shouldn't that be reported to Sinatra to fix? |
|
Workaround for non-docker installation: |
|
Solved the same error on 7.16.3 per suggestion from another thread by adding --preserve. RUN ${LS_HOME}/bin/logstash-plugin install --preserve logstash-input-kinesis Do you see any problem with this approach? Shall I use alternate solution from @matthew-muscat and update my Dockerfile? |
|
Digging into the history of the TIL. |
|
Thanks @yaauie the snapshot I had did not contain the fix, today's build passes. |
|
I was getting similar kind of error while installing logstash 1:7.16.1 [2022-02-17T04:45:10,663][FATAL][logstash.runner ] An unexpected error occurred! {:error=>#<ArgumentError: wrong number of arguments (given 3, expected 1..2)>, :backtrace=>["/usr/share/logstash/logstash-core/lib/logstash/api/modules/base.rb:43:in [2022-02-17T04:45:10,667][FATAL][org.logstash.Logstash ] Logstash stopped processing because of an error: (SystemExit) exit org.jruby.exceptions.SystemExit: (SystemExit) exit at org.jruby.RubyKernel.exit(org/jruby/RubyKernel.java:747) ~[jruby-complete-9.2.20.1.jar:?] at org.jruby.RubyKernel.exit(org/jruby/RubyKernel.java:710) ~[jruby-complete-9.2.20.1.jar:?] at usr.share.logstash.lib.bootstrap.environment.(/usr/share/logstash/lib/bootstrap/environment.rb:94) ~[?:?] So in our installation script where we are adding plugins while installing logstash added --preserve , we are using ansible to install .
|
|
Is there an expected release date for |
But I do not see any changes to the Gemfile.lock with regards to sinatra, ... and Logtash boots up just fine.
7.17.1, which includes a the sinatra pin, MIGHT be out next week (if nothing unexpected comes up) Also planning to further improve the plugin install/update process in 7.17.2 with regards to any dependency updates that might happen while installing/updating plugins. |
|
I mistakenly thought @kares solution was working for me, only to find the following error: sed --in-place "s/gem.add_runtime_dependency \"sinatra\", '~> 2'/gem.add_runtime_dependency \"sinatra\", '~> 2.1.0'/g" /usr/share/logstash/logstash-core/logstash-core.gemspec
/usr/share/logstash/bin/logstash-plugin install logstash-output-amazon_es
Using bundled JDK: /usr/share/logstash/jdk
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Validating logstash-output-amazon_es
Installing logstash-output-amazon_es
Plugin version conflict, aborting
ERROR: Installation Aborted, message: Bundler could not find compatible versions for gem "sinatra":
In snapshot (Gemfile.lock):
sinatra (= 2.2.0)
In Gemfile:
logstash-core was resolved to 7.16.1, which depends on
sinatra (~> 2.1.0)
Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.Apologize that I'm a bit ignorant with bundler but I've tried the recommended |
@reedflinch this is going to be the blind leading the blind, but a couple of guesses: and then when installing the plugin it might be best to use |
Sorry to hear that, maybe the best action is to simply re-install Logstash and start over. Also, whenever doing |
|
Appreciate everyone's help, thank you 🙏 The best solution for me, until a patched Logstash version is released, was to simply roll back our AMI to the last version. I could never get the gem/bundle changes to play nicely.
I suspect this might line up with what I was seeing. |
|
some trouble. this workaround (#13777 (comment)) does't help me. Automaticaly fixed after update from logstash-7.16.2-1.x86_64 to logstash-7.17.1-1.x86_64 |
|
going to close the issue - it's still going to potentially affect older LS versions but since 7.17.2 and 8.1.1 LS does conservative plugin updates by default which is expected to minimize the updates on transitive dependencies. |
|
and just for the record sinatra still hasn't released an updated version (after 2.2.0 released in Feb/2022) that would unbreak JRuby |
Plugins installed:
logstash-filter-json
logstash-filter-bytes
logstash-filter-extractnumbers
logstash-input-http_poller
logstash-input-http
logstash-input-redis
logstash-input-imap
logstash-input-tcp
logstash-input-udp
logstash-input-redis
logstash-input-syslog
logstash-input-snmp
Installation is based on this repo: https://github.com/deviantony/docker-elk
Description of the problem including expected versus actual behavior:
Steps to reproduce:
Log of the crash:
The text was updated successfully, but these errors were encountered: