we're working on a ruby on rails (4.2.8) application which is running on jruby-1.7.25. It really is time to update this mummy to the latest version 9.1.7.0. We did that and for most of my colleagues it works out fine. But - guess what - not for me. Before posting my question here, I made sure that:
I have the same setup
Same DB content
The exactly same code
as the others, but I still get that stupid error which is
java.lang.NullPointerException and that's really all, the app is spitting out on any request.
I was digging for the last hours and found out, that the real issue is getting lost in the depth of logging. Finally I found, that I will see the real cause if I add a puts in the file vendor/jruby/2.3.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/show_exceptions.rb like:
class ShowExceptions
FAILSAFE_RESPONSE = [500, { 'Content-Type' => 'text/plain' },
["500 Internal Server Error\n" \
"If you are the administrator of this website, then please read this web " \
"application's log file and/or the web server's log file to find out what " \
"went wrong."]]
def initialize(app, exceptions_app)
#app = app
#exceptions_app = exceptions_app
end
def call(env)
#app.call(env)
rescue Exception => exception
puts "EXCEPTION: #{exception.inspect}\n#app: #{#app.inspect}\nENV: #{env.inspect}"
if env['action_dispatch.show_exceptions'] == false
raise exception
else
render_exception(env, exception)
end
end
The output is:
EXCEPTION: #<NoMethodError: undefined method `bindings' for java.lang.NullPointerException:Java::JavaLang::NullPointerException
#app and env print out kilobytes of data which probably do not help. Honestly, I'm kind of stuck here. How can it work on other machines while it fails on mine? Has anyone of you had a similar issue or any idea what causes this trouble?
Ah, some version infos
Puma: * Version 3.7.1 (jruby 9.1.7.0 - ruby 2.3.1), codename: Snowy Sagebrush
jruby: jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 24.79-b02 on 1.7.0_79-b15 +jit [darwin-x86_64]
java: java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Mac OSX: 10.12.3 (16D32)
Thanks for any hints!
Related
My Ruby on Rails application remotely starts some scripts on a distant SuSe server (SUSE Linux Enterprise Server 15 SP2). It relies on the net-ssh gem which is declared in the Gemfile: gem 'net-ssh'.
The script is triggerd remotely through the following block:
Net::SSH.start(remote_host, remote_user, password: remote_password) do |ssh|
feed_back = ssh.exec!("#{event.statement}")
end
This works as expected as long as long as the Rails server runs on Windows Server 2016, which is my DEV environment. But when I deploy to the Validation environment, which is SUSE Linux Enterprise Server 15 SP2, I get this error message:
Errno::ENOTTY in myController#myMethod
Inappropriate ioctl for device
On another hand, issuing the SSH request through the command line - from SUSE to SUSE - works as expected too. Reading around I did not find a relevant parameter for the Net::SSH module to solve this.
Your suggestions are welcome!
I finally found out that the message refers to the operating mode of SSH: it requires a sort of terminal emulation - so called pty - wrapped into a SSH chanel.
So I implemented it this way:
Net::SSH.start(remote_host, remote_user, password: remote_password) do |session|
session.open_channel do |channel|
channel.request_pty do |ch, success|
raise "Error requesting pty" unless success
puts "------------ pty successfully obtained"
end
channel.exec "#{#task.statement}" do |ch, success|
abort "could not execute command" unless success
channel.on_data do |ch, data|
puts "------------ got stdout: #{data}"
#task.update_attribute(:return_value, data)
end
channel.on_extended_data do |ch, type, data|
puts "------------ got stderr: #{data}"
end
channel.on_close do |ch|
puts "------------ channel is closing!"
end
end
end
### Wait until the session closes
session.loop
end
This solved my issue.
Note:
The answer proposed above was only a part of the solution. The same error occured again with this source code when deploying to the production server.
The issue appears to be the password to the SSH target: I retyped it by hand instead of doing the usual copy/paste from MS Excel, and the SSH connection is now successful!
As the error raised is not a simple "connection refused", I suspect that the password string had a specific character encoding, or an unexpected ending character.
As the first proposed solution provides a working example, I leave it there.
Hi all can anyone help me to resolve the issue
'ArgumentError: cannot interpret as DNS name: nil'
The error is coming when doing capybara selenium integration testing in rails 4
here I am using jruby-1.7.9 and ruby version inside JRuby is 2.0.0p195
already I had used the Ruby version is 1.9.7 at that time I faced the error
'cant connect to chrome driver error'
in pure ruby like without using JRuby its the integration testing is working. but my application is in JRuby. and I am using ubuntu platform.
So anyone have any solution on this. what should I do to resolve this??
Here iam adding the exception backtrace
["/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:1181:in create'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:1027:ingenerate_candidates'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:1052:in resolv'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:518:ineach_resource'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:411:in each_address'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:120:ineach_address'", "org/jruby/RubyArray.java:1613:in each'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:119:ineach_address'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:97:in getaddress'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:48:ingetaddress'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/1.9/resolv-replace.rb:10:in getaddress'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/1.9/resolv-replace.rb:22:ininitialize'", "org/jruby/RubyIO.java:1178:in open'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:882:inconnect'", "org/jruby/ext/timeout/Timeout.java:144:in timeout'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:881:inconnect'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:866:in do_start'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:855:instart'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:582:in start'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/server.rb:81:inresponsive?'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/server.rb:97:in boot'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/session.rb:72:ininitialize'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara.rb:324:in current_session'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/dsl.rb:47:inpage'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/dsl.rb:52:in visit'", "/media/sidharthan/NewVolume/sidharthan_fooddev/foodapp/webapp/food/test/test_helper.rb:115:inIntegrationTest'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara.rb:67:in configure'", "/media/sidharthan/NewVolume/sidharthan_fooddev/foodapp/webapp/food/test/test_helper.rb:102:inIntegrationTest'", "org/jruby/RubyBasicObject.java:1565:in instance_exec'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:446:inmake_lambda'", "org/jruby/RubyProc.java:271:in call'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:192:insimple'", "org/jruby/RubyProc.java:271:in call'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:504:incall'", "org/jruby/RubyArray.java:1613:in each'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:504:incall'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:92:in __run_callbacks__'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:782:in_run_setup_callbacks'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:81:in run_callbacks'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/testing/setup_and_teardown.rb:41:inbefore_setup'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activerecord-4.2.6/lib/active_record/fixtures.rb:827:in before_setup'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:105:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:204:in capture_exceptions'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:104:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:255:in time_it'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:103:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:348:in on_signal'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:275:inwith_info_handler'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:102:in run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:799:inrun_one_method'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:322:in run_one_method'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:310:inrun'", "org/jruby/RubyArray.java:1613:in each'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:309:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:348:in on_signal'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:335:inwith_info_handler'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:308:in run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:158:in__run'", "org/jruby/RubyArray.java:2409:in map'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:158:in__run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:135:in run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:62:inautorun'"]
Thanks in advance
From the stacktrace you can see it's erring inside https://github.com/teamcapybara/capybara/blob/2.9.1/lib/capybara/server.rb#L81 - which is while Capybara is waiting for the application to be tested to start up.
This could mean you have set Capybara.server_host or Capybara.server_port incorrectly. Without the real code you're running that generates the stacktrace it's impossible to say.
You also probably want to update to the latest 2.x version of Capybara -- 2.9.1 is really old.
I’m using Ruby on Rails 4.2.7 on Mac El Capitan and just installed the Tor browser (v 6.0.4). I fired up my Tor browser, have verified its running by viewing a couple of web pages, but using this gem — https://github.com/dryruby/tor.rb , when I run my script, Ruby doesn’t believe Tor is running
require 'tor'
...
puts "avaailble: #{Tor.available?}"
puts "version: #{Tor.version}"
Returns
avaailble: false
version:
Indeed, when I try and make a Tor request using the https://github.com/brunogh/tor_requests gem, the web page request returns immediately, leading me to believe the Tor network isn’t being used because in a Tor browser it takes much longer (here is the code I’m using to amen a web page request) …
uri = URI.parse(url)
Net::HTTP.SOCKSProxy('127.0.0.1', 9150).start(uri.host, uri.port) do |http|
f = http.get(uri.path)
end
How do I make my Ruby/Rails code connect to my locally running Tor network?
Edit: In respnse to the answer given, here is what I set my PATH and DYLD_LIBRARY_PATH variables to …
localhost:myproject davea$ echo $PATH
/usr/local/opt/coreutils/libexec/gnubin:/opt/local/bin:/opt/local/sbin:/Users/davea/.rvm/gems/ruby-2.3.0/bin:/Users/davea/.rvm/gems/ruby-2.3.0#global/bin:/Users/davea/.rvm/rubies/ruby-2.3.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/mysql/bin/:/opt/gradle-2.7/bin:/opt/apache-maven-3.3.3/bin:/Users/ davea/.rvm/bin:/usr/local/mysql/bin:/Applications/TorBrowser.app/Contents/MacOS/Tor:/Users/davea/.rvm/bin:/usr/local/mysql/bin:/Applications/TorBrowser.app/Contents/MacOS/Tor
localhost:myproject davea$ echo $DYLD_LIBRARY_PATH
/Applications/TorBrowser.app/Contents/MacOS/Tor:/usr/local/mysql/lib:/usr/local/mysql/lib:
and here is ht output in my Rails console trying the commands listed …
localhost:myproject davea$ rails console
Running via Spring preloader in process 49987
Loading development environment (Rails 4.2.7.1)
2.3.0 :001 >
2.3.0 :002 > Tor::Config::CONFDIR = '/Applications/TorBrowser.app//Contents/MacOS/Tor'
(irb):2: warning: already initialized constant Tor::Config::CONFDIR
/Users/davea/.rvm/gems/ruby-2.3.0/gems/tor-0.1.2/lib/tor/config.rb:21: warning: previous definition of CONFDIR was here
=> "/Applications/TorBrowser.app//Contents/MacOS/Tor"
2.3.0 :003 > Tor.available?
Here is how you can make brunogh/tor_requests work with Tor Browser (easy):
require 'tor_requests'
Tor.configure do |config|
config.ip = "127.0.0.1"
config.port = "9150"
config.add_header('User-Agent', 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0')
end
res = Tor::HTTP.get(URI('https://drew-phillips.com/ip-info/'))
p res.code
p res.body
To get dryruby/tor working involved a bit more work:
It depends on your ENV PATH variable to find the Tor binary and Tor browser has some libraries (at least on Linux) within it's path that aren't found if you try to execute it directly. Seems this should support allowing you to add the path in code instead of relying on PATH in my opinion.
Trying to run Tor Browser's tor binary from the console yields (more on this later, may not apply to Mac):
tor: symbol lookup error: tor-browser_en-US/Browser/TorBrowser/Tor/tor: undefined
symbol: evutil_secure_rng_set_urandom_device_file
Also, installing the Gem from source doesn't give us the latest version available on GitHub and there appears to be a fix to the version method that isn't included with the Gem version 0.1.2. Because of this I pulled the source and tell the program to load the Gem from a custom path.
The working code:
require 'rubygems'
$:.unshift "./tor/lib"
require 'tor'
Tor::Config::CONFDIR = '/home/me/tor-browser_en-US/Browser/TorBrowser/Data/Tor'
p Tor::Config::CONFDIR
p Tor.available?
p Tor.version
Now, in order to have it run successfully, you'll need to set your PATH and LD_LIBRARY_PATH (on Mac this is DYLD_LIBRARY_PATH I believe).
So I run the Ruby code like this:
PATH=/home/me/tor-browser_en-US/Browser/TorBrowser/Tor:$PATH \
LD_LIBRARY_PATH=/home/me/tor-browser_en-US/Browser/TorBrowser/Tor:$LD_LIBRARY_PATH \
ruby tor.rb
This puts Tor Browser as the first search path for binaries and libraries.
Then with this I was able to get the following output:
true
"0.2.8.6"
Hope that helps!
I am trying to connect to the XMLRPC API of a dokuwiki website.
I am successfully doing that from my own laptop, with a SSL connection, however, when I try to do it from my production server (which hosts both the wiki and the rails app from which the ruby code is executed), I run into a
Runtime Error
Wrong size. Was 163, should be 113
Here's how I initialize the connection :
#wiki = ::XMLRPC::Client.new3(
host: "wiki.example.com",
path: "/lib/exe/xmlrpc.php",
use_ssl: true)
# Temp Hack because SSL Fails
#wiki.instance_variable_get(:#http).instance_variable_set(:#verify_mode, OpenSSL::SSL::VERIFY_NONE)
end
#authenticated = false
authenticate!
end
def authenticate!
# Fails at below line :
#authenticated = #wiki.call("dokuwiki.login", ENV['WIKI_USER'], ENV['WIKI_PASSWORD'])
Rails.logger.info (#authenticated ? "Authenticated on Wiki !" : "Authentication failed on wiki !")
end
I've read many posts saying that there is a bug in the XMLRPC lib of Ruby. I was running ruby 2.1.5pxx on my laptop and ruby 1.9.xx at my server so I did a rvm install 2.1.5, yet the problem is still here
(btw, I assumed it was enough to do a rvm use 2.1.5 and then touch restart to restart my rails server, but how can I check which version of ruby it's using ?)
What is wrong ?
EDIT
On my laptop, I am running ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
On my production server, I am running ruby-2.1.5 [ i686 ]
I tried another library, libxml-xmlrpc, and I get the following error when running the same command:
Net::HTTPBadResponse: wrong status line: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">"
But again, the same code is running fine with the default ruby xmlrpc client on my Windows + rubyx64 2.1.5, so I really don't get it!
Edit2 : I tried adding
#wiki.http_header_extra = { "accept-encoding" => "identity" }
But then I get a
Authorization failed. HTTP-Error: 401 Unauthorized
The first call #wiki.call("dokuwiki.login", "myUsr", "myPwd") worked, but apparently it failed to authenticate me (Of course I am still using the same login information that should work)
EDIT 3
After investigation, a successful login from any other computer than localhost will set a cookie like
#cookie="DokuWiki=[small string] ; [very big string]
Whereas if I do it on localhost :
I will write [...] for random strings
#cookie="[small string 2]=deleted; DokuWiki=[small string]; [very big string]"
So I have an extra variable info stored in my cookie, which is "[small string 2]=deleted;
I believe this is what makes my authentication fails. Anyone knows what this is ???
So this localhost connection was messing up with the cookie. Apparently, even the ruby library doesn't know why, and the "Wrong size" comes from this unexpected string [random string]=deleted added at the beginning of the cookie.
Unless someone can explain WHY such a string is added, I will accept my solution of simply adding
#wiki.http_header_extra = { "accept-encoding" => "identity" }
which removes the "Wrong size" error, then
if /deleted/.match(#wiki.cookie)
#wiki.cookie = #wiki.cookie.gsub(/.*deleted; /, '')
end
To remove the beginning of the cookie
I'm having an issue with the latest puppet version and a module called vcsdeploy. Unfortunately I'm not familiar with Ruby and it's own idiosyncrasies, so I'm hoping someone with a little more experience can point me in the right direction.
The module in question can be found here in all it's glory. The particular issue I'm experiencing is an error at line 194 in lib/puppet/provider/vcsdeploy/svn.rb: "Could not evaluate: undefined class/module Puppet::Util::TagSet"
For those who don't want to spelunk the source code, here's the code that's causing the error:
valid_options = [ 'path', 'owner', 'group', 'dirmode', 'filemode', 'source', 'user', 'pass', 'name', 'version', 'selrange', 'selrole', 'seltype', 'seluser', 'templates' ]
#resource_copy = {}
debug "creating resource_copy for #{resource[:name]}"
valid_options.each {|option|
if (option && resource[option.to_sym])
#resource_copy[option.to_sym] = resource[option.to_sym]
end
}
I would assume that Puppet::Util::TagSet is used to some degree elsewhere throughout puppet and it's various modules however this is the only one that's causing a problem.
Anyone got any pointers that I could use to start this investigation?
More System Information:
Operating System: CentOS 6.5
Installation Method: RPM packages
Foreman Version: 1.5
Puppet Version: 3.5.1
I have also verified that the file tag_set.rb exists at the location:
/usr/lib/ruby/site_ruby/1.8/puppet/util/tag_set.rb
What the module fails to document is that it requires Puppet 3.3 which introduced this piece of code (see the commit).