77

I have a Ruby on Rails application that I am deploying on a computer running Mac OS X 10.6. The code where the problem arises is run by a delayed_job. The problem only occurs when it is run through delayed_job. If I run it within a console (rails console production) or call the API directly through cURL, it works without any problems. Also, the entire process works without issue in my development environment.

Basically, the code works in one place, but for some reason, fails where it has to work. I've searched and found a few resources, but none of the suggestions apply or make any difference. When I log into the server and run the commands, everything works. But for some reason when they are run/started by Capistrano, it doesn't work.

Any help is greatly appreciated.

Important notes:

  • Ruby version: 1.9.2-p0
  • Rails version: 3.0.1
  • delayed_job version: latest (from collectiveidea/delayed_job)
  • rest-client version: 1.6.1

Code:

class CallApi < Struct.new(:num)
  def perform
    log "Entering perform"
    apinum = num || 5
    log "ApiNum = #{apinum}"
    results = attempt(2,10) do
      ActiveSupport::JSON.decode(RestClient.get(API_URL, {:params => {:apinum => apinum}}))
    end
    log "Results retrieved. (count: #{results.count})"
  end

  def log(message)
    Delayed::Worker.logger.info "[CallApi] #{Time.now} - #{message}"
  end
end

Environment Config (note: the url is fake, but of the same form as the real one):

API_URL = "http://api.example.org/api_endpoint"
# Originally, I had "http://" before the beginning, but found a
# post mentioning that Net::Http.start didn't like that.
# So I tried it both ways.
# The same error occurs regardless of if the "http://" is there.

Call where the error happens:

RestClient.get(API_URL, {:params => {:apinum => apinum}})

Error:

getaddrinfo: nodename nor servname provided, or not known
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `initialize'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `open'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `block in connect'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/timeout.rb:44:in `timeout'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/timeout.rb:87:in `timeout'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `connect'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:637:in `do_start'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:626:in `start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient/request.rb:166:in `transmit'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient/request.rb:60:in `execute'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient/request.rb:31:in `execute'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient.rb:68:in `get'
/private/var/www/project-gemset/releases/20101109002137/lib/call_api.rb:7:in `block in perform'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/attempt-0.2.0/lib/attempt.rb:70:in `attempt'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/attempt-0.2.0/lib/attempt.rb:114:in `attempt'
/private/var/www/project-gemset/releases/20101109002137/lib/call_api.rb:6:in `perform'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/backend/base.rb:77:in `invoke_job'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:118:in `block (2 levels) in run'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/timeout.rb:57:in `timeout'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:118:in `block in run'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/benchmark.rb:309:in `realtime'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:117:in `run'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:176:in `reserve_and_run_one_job'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:102:in `block in work_off'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:101:in `times'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:101:in `work_off'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:76:in `block (2 levels) in start'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/benchmark.rb:309:in `realtime'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:75:in `block in start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:72:in `loop'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:72:in `start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:100:in `run'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:79:in `block in run_process'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:250:in `call'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:250:in `block in start_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/daemonize.rb:199:in `call'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/daemonize.rb:199:in `call_as_daemon'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:254:in `start_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:294:in `start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:159:in `block (2 levels) in start_all'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:158:in `fork'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:158:in `block in start_all'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:157:in `each'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:157:in `start_all'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/controller.rb:80:in `run'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons.rb:193:in `block in run_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:in `call'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:in `catch_exceptions'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons.rb:192:in `run_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:78:in `run_process'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:72:in `block in daemonize'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:70:in `times'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:70:in `daemonize'
script/delayed_job:5:in `'
ChronoPositron
  • 1,498
  • 2
  • 10
  • 14
  • I got this message out of the blue while trying to send an email via Postmark. It turned out their DNS was having a problem resolving so this is what the error appeared like on our Rails app. – Joshua Pinter Oct 21 '16 at 19:26

13 Answers13

55

The error occurs when the DNS resolution fails. Check if you can wget (or curl) the api url from the command line. Changing the DNS server and testing it might help.

Vijay Dev
  • 26,966
  • 21
  • 76
  • 96
  • 3
    While this does appear to be the technical thing that is going wrong, I'm still at a loss for why it happens. When I log into the server and run the commands, everything works. But for some reason when they are run/started by Capistrano, it doesn't work. Since I haven't found any way to fix it, I'm just going to accept this answer and give everyone else a vote. – ChronoPositron Nov 15 '10 at 22:01
  • 4
    Woke up my Mac from sleep, ran some cucumber tests, and got this error. I toggled my wifi off then on, and it worked. Seems to indeed be DNS related but that fixed it. – Matt Vukas Oct 21 '15 at 16:39
  • 1
    helps to check if any http proxy is to be set or not – OkraSala Jan 26 '17 at 06:39
10

I fixed this problem simply by closing and reopening the Terminal.

Bagus Aji Santoso
  • 507
  • 1
  • 7
  • 16
  • In my case, both `nslookup` and `dig` work fine, but `curl` doesn't. Completely quitting my Macbook's `Terminal` app (actually, I use `Iterm2` app) and relaunching it solved the problem. – Vincent Yin Jan 11 '22 at 20:41
10

rest-client's RestClient needs the http: scheme when resolving the URL. It calls Net::HTTP for you, which doesn't want the http: part, but rest-client takes care of that.

Is the URL the actual one you are attempting to reach? example.org is a valid domain used for testing and documentation and is reachable; I'd expect the "api" and "api_endpoint" parts to fail and see that when I try to reach them.

require 'socket'

IPSocket.getaddress('example.org') # => "2620:0:2d0:200::10"
IPSocket.getaddress('api.example.org') # => 
# ~> -:7:in `getaddress': getaddrinfo: nodename nor servname provided, or not known (SocketError)
# ~>    from -:7:in `<main>'

Here's what I get using Curl:

greg-mbp-wireless:~ greg$ curl api.example.org/api_endpoint
curl: (6) Couldn't resolve host 'api.example.org'
greg-mbp-wireless:~ greg$ curl example.org/api_endpoint
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /api_endpoint was not found on this server.</p>
<hr>
<address>Apache Server at example.org Port 80</address>
</body></html>
greg-mbp-wireless:~ greg$ curl example.org
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
  <META http-equiv="Content-Type" content="text/html; charset=utf-8">
  <TITLE>Example Web Page</TITLE>
</HEAD> 
<body>  
<p>You have reached this web page by typing &quot;example.com&quot;,
&quot;example.net&quot;,&quot;example.org&quot
  or &quot;example.edu&quot; into your web browser.</p>
<p>These domain names are reserved for use in documentation and are not available 
  for registration. See <a href="http://www.rfc-editor.org/rfc/rfc2606.txt">RFC 
  2606</a>, Section 3.</p>
</BODY>
</HTML>
the Tin Man
  • 158,662
  • 42
  • 215
  • 303
  • The API_URL I have in the question is just a fake example url that follows the same format as the real one. Running those commands directly on the server with the real url works and returns everything as I would expect. It seems that the problem only occurs when delayed_job is started via Capistrano. (I'll edit the question to make note of this) – ChronoPositron Nov 11 '10 at 07:25
  • Ah. Ok. example.com and it's siblings are for documentation, but lots of people try to use it for testing, which won't take them too far. – the Tin Man Nov 11 '10 at 18:01
10

I ran into a similar situation today - deploying an app to a mac os x server, and receiving the 'getaddrinfo' message when I tried to access an external api. It turns out that the error occurs when the ssh session that originally launched the app is no longer active. That's why everything works perfectly if you ssh into your server and run commands manually (or launch the server manually) - as long as you keep your ssh session alive, this error won't occur.

Whether this is a bug or a quirk in OS X, I'm not sure. Here's the page that led me to the solution - http://lists.apple.com/archives/unix-porting/2010/Jul/msg00001.html

All I had to do was update my capistrano task to launch the app using 'nohup'. So changing

run "cd #{current_path} && RAILS_ENV=production unicorn_rails -c config/unicorn.rb -D"

to

run "cd #{current_path} && RAILS_ENV=production nohup unicorn_rails -c config/unicorn.rb -D"

did the trick for me.

Hope this helps somebody - it was quite a pain to figure out!

Joshua Kunzmann
  • 930
  • 1
  • 8
  • 10
  • For those having this problem with `resque` you can run rake with `nohup` and this will solve the problem. i.e. `bundle exec nohup rake resque:work`. Thanks Joshua! – ipd Jan 16 '13 at 21:40
6

To avoid this problem, we can bind to 127.0.0.1 instead of localhost:

bin/rails server -b 127.0.0.1

David Zhang
  • 468
  • 7
  • 10
6

I got the same error when I check the localhost is set in hosts file it is somehow not set. Setting localhost to 127.0.0.1 solved it.

sudo vi /etc/hosts
>>

127.0.0.1       localhost
Mesut GUNES
  • 7,089
  • 2
  • 32
  • 49
5

I restarted my computer (Mac Mountain Lion) and the problem fixed itself. Something having to do with the shell thinking it was disconnected from the internet I think.

Restarting your shell in some definite way may solve this problem as well. Simply opening up a new session/window however did not work.

coloradoblue
  • 625
  • 7
  • 11
2

I was seeing this error unrelated to rails. It turned out my test was trying to use a port that was too high (greater than 65535).

This code will produce the error in question

require 'socket'
Socket.getaddrinfo("127.0.0.1", "65536")
Muir
  • 442
  • 4
  • 8
2

For me, I had to change a line of code in my local_env.yml to get the rspec tests to run.

I had originally had:

REDIS_HOST: 'redis'

and changed it to:

REDIS_HOST: 'localhost'

and the test ran fine.

Steve
  • 117
  • 1
  • 10
1

In my config/application.yml I have changed this

redis:
    url: "redis://redis:6379/0"

to this

redis:
    url: "redis://localhost:6379/0"

and it works for me

Ruslan Valeev
  • 1,529
  • 13
  • 24
  • and I forgot to execute redis instance after changed this... sob... this is correct if the redis is at local environment. – V-SHY Apr 02 '20 at 10:17
0

I got the error while trying to develop while disconnected to the Internet. However, the website I was working on needs to be able to talk to some other websites, so it choked when it couldn't do so. Connecting to the internet fixed the error.

Kevin
  • 14,655
  • 24
  • 74
  • 124
0

If all of the above fails, try to convert to UNIX Line Endings, or do:

brew install dos2unix
sudo dos2unix -c mac /private/etc/hosts

Maybe the hosts encoding is wrong.

hope this helps

oschvr
  • 422
  • 7
  • 15
0

I had this problem running rake db:create. This page clued me into the DNS issue. I checked my VPN connection and found it was disconnected for some reason. I reconnected and now rake worked without a hitch.

David Hempy
  • 5,373
  • 2
  • 40
  • 68