FreeBSD Rubyists? Do Remote Objects work for you?

[Miles Keaton]

Looking for any Ruby users on FreeBSD.

I think Ruby in FreeBSD freezes when receiving a reference to a remote object.

Can you please try the code-sample, here?
http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classes/DRb.html
The one under the header "Remote objects under dRuby", halfway down the page.

Try having it communicate across two different computers, where
FreeBSD is the server.

Can you get it to work?

For me, on many different FreeBSD boxes, it freezes when it tries to
call this line:
logger.log("Hello, world!")
Everything works until that point.

This same freeze happens with
http://pragmaticprogrammer.com/titles/ruby/code/smp670.html

It works when both processes are on the same box, but not if they are
on two separate computers.

What they all have in common is DRbUndumped - so I'm guessing that's
the problem.

But I can't for the life of me figure out what would make a FreeBSD
server not-respond when receiving a reference to a remote object.

If you pass a copy of the object, with Class defined on both sides, it
works fine.

But if you make it a reference to the original object, it doesn't respond.

Is this a Ruby bug or a FreeBSD threads-bug?

 

[Dick Davies]

Looking for any Ruby users on FreeBSD.

I think Ruby in FreeBSD freezes when receiving a reference to a remote object.

Can you please try the code-sample, here?
http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classes/DRb.html
The one under the header "Remote objects under dRuby", halfway down the page.

Try having it communicate across two different computers, where
FreeBSD is the server.

Can you get it to work?

Yeah, fine here (yesterdays stable on client and server).

Firewall?

 

[Brian McCallister]

Works fine for me as well under 5.3 and ruby 1.8.2 from ports.

brianm@morphy:~$ uname -a && ruby -v
FreeBSD morphy.skife.org 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5
04:19:18 UTC 2004
(e-mail address removed):/usr/obj/usr/src/sys/GENERIC i386
ruby 1.8.2 (2004-12-25) [i386-freebsd5]
brianm@morphy:~$

-Brian

 

[Mark Probert]

Hi ..

I think Ruby in FreeBSD freezes when receiving a reference to a remote
object.

Worked fine on my FreeBSD (5.3-RELEASE) with ruby 1.8.2 (2004-12-25)
[i386-freebsd5.3] with a Win2k client.

Can you please try the code-sample, here?

I needed to modify this code to make it work correctly. The code as posted
won't be able to write the logger to a non-existing directory (/tmp/dlog).
Change the logger.initialize to look something like (require 'ftools'):

def initialize(n, dir, fname)
@name = n
File.makedirs(dir)
@filename = dir + "/" + fname
end

With the appropriate change in the Factory creation did the trick for me.

Is this a Ruby bug or a FreeBSD threads-bug?

If it is still a problem, the next question would be about the kernel you are
running. Is it the standard kernel or has it been modified? If so, how?

HTH,

 

[Miles Keaton]

Looking for any Ruby users on FreeBSD.

I think Ruby in FreeBSD freezes when receiving a reference to a remote object.

Can you please try the code-sample, here?
http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classes/DRb.html
The one under the header "Remote objects under dRuby", halfway down the page.

Try having it communicate across two different computers, where
FreeBSD is the server.

Can you get it to work?

For me, on many different FreeBSD boxes, it freezes when it tries to
call this line:
logger.log("Hello, world!")
Everything works until that point.

This same freeze happens with
http://pragmaticprogrammer.com/titles/ruby/code/smp670.html

It works when both processes are on the same box, but not if they are
on two separate computers.

What they all have in common is DRbUndumped - so I'm guessing that's
the problem.

But I can't for the life of me figure out what would make a FreeBSD
server not-respond when receiving a reference to a remote object.

If you pass a copy of the object, with Class defined on both sides, it
works fine.

But if you make it a reference to the original object, it doesn't respond.

Is this a Ruby bug or a FreeBSD threads-bug?

Thanks for the replies, guys. I've spent about 12 hours on this so
far, and I'm still totally stumped, though, could anyone take a quick
look at this and see if they have any other ideas?

- I reverted my FreeBSD 5.3 back to the default GENERIC kernel. No change.
- I completely shut off all firewalls all around. No change.
- I tried newest stable-CVS build of Ruby. No change.

Here are my results with the EXACT SAME client.rb and server.rb
scripts all running the newest stable Ruby 1.8.2 (2004-12-25) on
different computers, all with no firewall, and all (except Linux)
right next to eachother on the same 192.168.0.* subnet

DRb TESTS:

CLIENT SERVER SUCCESS?
Mac Mac YES!
FreeBSD Mac no
Mac FreeBSD no
FreeBSD FreeBSD no
OpenBSD Linux YES
Mac Linux YES
FreeBSD Linux YES
FreeBSD OpenBSD YES

In other words:
If Linux is the server, ALL work.
If OpenBSD is the server, ALL work.
If Mac is the server, MAC works.
If FreeBSD is the server, NONE work.


I've got it printing all these little "I'm here" statements, so I know
exactly where it dies.

DRb server returns a reference to an object where class = "Logger" and
object_id = 67897744.
Client receives an object where class = "DRb:RbObject" and object_id
is 364316.

It gets as far as saying it received the Object-reference back, and
can call local/generic kernel methods on it like .class and .object_id

But when I try to call any remote methods on the Object-reference, it
waits for a few minutes, then gives this error:

/usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
#<Errno::ETIMEDOUT: Operation timed out - connect(2)> (DRb:RbConnError)

(All platforms die at that exact same line. Same error.)

Could it be that a remote-method called on a DRbUndumped
object-reference sends a different kind of TCP/IP packet than all the
other successful DRb calls up to that point?

Can anyone think of anything else it might be?

I'm not just hobbying with this. I really need to use DRb for work.
Thanks!

 

[Mark Probert]

Hi ..

/usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
#<Errno::ETIMEDOUT: Operation timed out - connect(2)> (DRb:RbConnError)

(All platforms die at that exact same line.  Same error.)

Your problem is in here, somewhere, I would think ;-)

If connect is timing out, there is something that is blocking it, router,
filter, firewall or whatever. I don't think that this you may have a network
config issue on your hands.

Regards,

 

[Miles Keaton]

Your problem is in here, somewhere, I would think ;-)

If connect is timing out, there is something that is blocking it, router,
filter, firewall or whatever. I don't think that this you may have a network
config issue on your hands.

I would have thought so, except that everything else in DRb works
*except* passing an object by reference.

I've spent a whole day testing all kinds of dRuby client-server-remote
things and they all work fine... until you try to call a method on a
remote object that's been passed by reference.

I don't understand how (or if) objects passed by reference would have
such a different TCP/IP packet.

Can anyone imagine what might be blocking this kind of activity, but
not others? I've been poring through the drb.rb code for an hour
now, and can't figure out what it might be.

 

[Eric Hodel]

I would have thought so, except that everything else in DRb works
*except* passing an object by reference.

I've spent a whole day testing all kinds of dRuby client-server-remote
things and they all work fine... until you try to call a method on a
remote object that's been passed by reference.

I don't understand how (or if) objects passed by reference would have
such a different TCP/IP packet.

Can anyone imagine what might be blocking this kind of activity, but
not others? I've been poring through the drb.rb code for an hour
now, and can't figure out what it might be.

I had a similar problem, the server was connecting back to a client on
a port that wasn't open. I would get a connection refused, rather than
a timeout. This is on 4.x, but I haven't had time to look into it
further.

 

[Brian Candler]

I would have thought so, except that everything else in DRb works
*except* passing an object by reference.

It would

http://www.rubygarden.org/ruby?DrbTutorial
describes how this DRbUndumped stuff works, and may make things clearer,
especially the section headed "Why does the client run 'DRb.start_service'?"

You'll find that with DRbUndumped, the 'server' will end up opening a fresh
TCP connection back to the 'client'

The easy way for you to prove that it's a network issue is to put the two
FreeBSD boxes on the *same subnet* (i.e. with no router or anything in
between)

Then, once the machines are back where they were before, the solution may
involve:
- sticking the client on a fixed port number, so that you can open a
firewall hole for connections backwards from the server to the client; or
- running DRb over ssh, which is also described in that document.

Regards,

Brian.

 

[Brian Candler]

You'll find that with DRbUndumped, the 'server' will end up opening a fresh
TCP connection back to the 'client'

The easy way for you to prove that it's a network issue is to put the two
FreeBSD boxes on the *same subnet* (i.e. with no router or anything in
between)

Oh, and one other thing: the client side machine will read its own system
hostname (as shown by 'hostname' on many Unix systems), and pass that across
to the server. At the time it wishes to connect back, the server will then
try to resolve that name back to an IP address.

So it's important that 'hostname' contains a real hostname and your DNS is
working, or at least at the server side you have an entry in /etc/hosts for
the client host.

B.

 

[Miles Keaton]

the client side machine will read its own system
hostname (as shown by 'hostname' on many Unix systems), and pass that across
to the server. At the time it wishes to connect back, the server will then
try to resolve that name back to an IP address.
So it's important that 'hostname' contains a real hostname and your DNS is
working, or at least at the server side you have an entry in /etc/hosts for
the client host.

Oh... my.... god.

THIS JUST SOLVED EVERYTHING!

15 hours of poring over every line of drb.rb, recompiling kernels,
physically disabling firewalls, downloading new CVS-stable Ruby, and
dozens and dozens of "hello world" tests, and it was the fucking
/etc/hosts file! We have dozens of machines that address eachother by
IP address, and had never needed to put each one's full hostname into
everyone's /etc/hosts ... until now.

Brian thanks so so so much.