Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#stop causes "Errno::ENOTCONN: Socket is not connected" in OSX #24

Closed
wconrad opened this issue May 12, 2014 · 8 comments
Closed

#stop causes "Errno::ENOTCONN: Socket is not connected" in OSX #24

wconrad opened this issue May 12, 2014 · 8 comments
Labels

Comments

@wconrad
Copy link
Owner

wconrad commented May 12, 2014

@jcarlson reports that the bug fix for #23 causes "Errno::ENOTCONN: Socket is not connected" in OSX when #stop is called on the server:


Unfortunately, this doesn't fix my problem. Now, on OS X, when I call server.stop, it raises an error immediately:

[6] pry(main)> server.stop
Errno::ENOTCONN: Socket is not connected
from /Users/dev/.rvm/gems/ruby-2.0.0-p353@corndog/gems/ftpd-0.14.0/lib/ftpd/server.rb:53:in `shutdown'

This is better because it fails fast, but obviously still an issue.

I'm on Ruby 2.0.0p353 on OS X 10.8.5. Our CI server is on Ubuntu.

FWIW, the reason I don't use a random port number is that my client code reads settings from a YAML file in the config directory. So when I setup my test server, I also read from that YAML file and have the server start on the port that the YAML file specifies. I guess I could hack around until I can make the port a sort of shared read/write global that the server can update when the port is known... but I don't particularly love that path.


Here's a couple test helper methods that seem to get the trick done with v0.11.0:

def start
  @thread = @server.start
  @running = true
end

def stop
  if @running
    @server.stop
    @thread.exit
  end
  @running = false
end
@wconrad
Copy link
Owner Author

wconrad commented May 12, 2014

OK, the hunt is on. Unfortunately, I don't have access to OSX, and I don't get that error in Debian. I'll do some thinking and googling and see what springs to mind.

@wconrad
Copy link
Owner Author

wconrad commented May 12, 2014

@jcarlson Here's how webrick, in Ruby's standard library, shuts down a server socket:

        begin
          s.shutdown
        rescue Errno::ENOTCONN
          # when `Errno::ENOTCONN: Socket is not connected' on some platforms,
          # call #close instead of #shutdown.
          # (ignore @config[:ShutdownSocketWithoutClose])
          s.close
        else
          unless @config[:ShutdownSocketWithoutClose]
            s.close
          end
        end

Based on that, I have an idea or two to try. I don't know if OSX makes it easy or hard to make local modifications to an installed gem, but if it isn't too hard, could you please try changing Server#stop, in file ftpd/lib/ftpd/server.rb, from this:

    def stop
      @stopping = true
      @server_socket.shutdown
      @server_socket.close
    end

to this:

    def stop
      @stopping = true
      begin
        @server_socket.shutdown
      rescue Errno::ENOTCONN
      end
      @server_socket.close
    end

and see what happens?

If it would be easier for you if I made a branch on github and put this (and other, future attempts) in that branch, then I'll do that. Bundler makes it pretty easy to pull a gem from a github branch. Just let me know.

@jcarlson
Copy link

If you can put it on a branch, I can test it on both my mac and push it to our CI server and test it there. I'll try to get to it today. If you don't have time to make a branch, I can clone the repo if necessary when I get to this today.

@wconrad
Copy link
Owner Author

wconrad commented May 13, 2014

Branch made. Here's the Gemfile line:

gem 'ftpd', github: 'wconrad/ftpd', branch: 'osx-socket-not-connected-error'

@jcarlson
Copy link

Okay, this worked on my OS X machine locally. I'm sending it to our CI server to test there and will report back shortly.

@jcarlson
Copy link

This also works on our CI server (Unix), so I think you nailed it.

@jcarlson
Copy link

Many thanks again for so quickly resolving this issue!

@wconrad
Copy link
Owner Author

wconrad commented May 14, 2014

@jcarlson You are welcome! Thank you for working so well with me on it. This one was kinda fun. The gem has been updated--if you get version 0.15.0, it'll have the fix.

@wconrad wconrad added the bug label May 14, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants