From: Gary Jaeger <gary@(email surpressed)>
Subject: no response
   Date: Fri, 25 Feb 2011 16:50:10 -0500

Hey Greg. Why would I get a "no response" from machines in rushadmin (and they show yellow caution bars in rushtop) but I can successfully rush -ping them?

. . . . . . . . . . . .
Gary Jaeger // Core Studio
86 Graham Street, Suite 120
San Francisco, CA 94129
(Tel# suppressed)
http://corestudio.com	

Gary Jaeger wrote:
> Hey Greg. Why would I get a "no response" from machines in rushadmin =
> (and they show yellow caution bars in rushtop) but I can successfully =
> rush -ping them?

	Two reasons I know of.

	1) The most common, a software firewall/virus software that's
	   blocking UDP (affects rush -push, rush -status, rushtop, All Cpus
	   and All Jobs..) but not blocking TCP (rush -ping, etc).

	2) A mismatch of MTU settings (for enabling jumbo frames) affects the
	   handling of UDP packet fragmentation in the kernels; make sure if
	   you tweak your MTUs, make the same change is made on all the boxes
	   (ie. consistent MTU settings), otherwise UDP packets get mangled. See:
	   http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1957+1958+1959+1960+1961+1962

    There might be other causes, but those are the biggies.. #1 in particular.

    Regarding #1, what OS are you running on?

    If windows, try stopping the rushd service (net stop rushd)
    and then, logged into the window manager as the user the rushd
    service normally runs as, try running 'rushd -nofork' from a
    DOS window, and see if any dialogs or errors pop up about
    allowing access to networking (indicating a selective firewall)

    If linux, try disabling iptables on boot, then either reboot
    or then use ipfw to clear the table, and see if that solves it.
    Or if you have firewalling on and want it to remain on,
    just be sure to make a 'hole' for port 696 for both TCP *and* UDP.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

mac. They are running now. Anecdotally it seemed as if they dropped off shortly after I pushed new host files out. running stop then start seems to have cleared it up. I'll test more on that asap and check the things you mentioned. But I have another more pressing issue... (email on the way)

On Feb 25, 2011, at 3:40 PM, Greg Ercolano wrote:

>    Regarding #1, what OS are you running on?

. . . . . . . . . . . .
Gary Jaeger // Core Studio
86 Graham Street, Suite 120
San Francisco, CA 94129
(Tel# suppressed)
http://corestudio.com	

Gary Jaeger wrote:
> [posted to rush.general]
> 
> mac. They are running now. Anecdotally it seemed as if they dropped off =
> shortly after I pushed new host files out. running stop then start seems =
> to have cleared it up. I'll test more on that asap and check the things =
> you mentioned. But I have another more pressing issue... (email on the =
> way)

	Try running:

		rush -lah <HOSTNAME_NOT_RESPONDING>

	..and see if there are any ???'s in place of the IP addresses.
	This asks the remote daemon to display its hostname<->IP lookup cache.

	???'s in place of an IP address would indicate a name lookup problem
	might be causing the response issue, in which case go over to that
	box and see what's causing the problem (eg. DNS client settings or some such).

	Also, check your rushd.log file to see if there are any errors.

	Follow up via private email with details, and I can provide a
	summary on this thread.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Gary Jaeger wrote:
> mac. They are running now. Anecdotally it seemed as if they
> dropped off shortly after I pushed new host files out.
> running stop then start seems to have cleared it up.

	OK, we discovered through private email you've got an
	older release of rush running on Snow Leopard.

	There was a maintenance release of Rush to support Leopard + Snow Leopard
	back in 2009; it solved a problem that caused the UDP port to close,
	as well as various other problems. One of the causes was pushing out
	a new hosts file. Basically this issue:
	http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1915+1914+1913+1912+1911+1910+1909+1908+1907

	This was fixed in the 102.42a9d maintenance release,
	so upgrading to the current release will fix it.
	Sounds like you're taking the upgrade now. Feel free
	to follow up if there's still a problem.