From: Dylan Penhale <dylan@(email surpressed).au>
Subject: more than one rushd.exe process on PC's
   Date: Fri, 14 Jul 2006 02:59:46 -0400

We are running rush 102.42

Regards

Dylan Penhale
Systems Administrator
Fuel International
65 King Street
Newtown
2042
Sydney
Australia
p. (Tel# suppressed)
f. (Tel# suppressed)

On Fri, July 14, 2006 02:59, Dylan Penhale wrote:
> [posted to rush.general]
>
> We are running rush 102.42
>
> Can you tell me if the rush -ljf bug mentioned in the update details
> for 102.42a6 applies to windows machines, and if the version we are
> running should suffer from this bug?
>
> We are seeing more than one rushd.exe pretty much all the time on
> windows hosts seemingly making them very slow to respond to iRush.

The bug doesn't affect windows; it's unix only.

There will be more than one rushd.exe process normally.. what would be
abnormal is if the extra rushd stays running for longer than a few seconds.
That means it's trying to access something it can't reach.

If you're having problems with slowness, check the rushd.log files for errors
and include them here.

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

** NOTE:
**    I will be on vacation July 11th through July 20th.
**    During that time, orders & email response may take over 24 hours.
**

|
|On Fri, July 14, 2006 02:59, Dylan Penhale wrote:
|> [posted to rush.general]
|>
|> We are running rush 102.42
|>
|> Can you tell me if the rush -ljf bug mentioned in the update details
|> for 102.42a6 applies to windows machines, and if the version we are
|> running should suffer from this bug?
|>
|> We are seeing more than one rushd.exe pretty much all the time on
|> windows hosts seemingly making them very slow to respond to iRush.
|
|The bug doesn't affect windows; it's unix only.
|
|There will be more than one rushd.exe process normally.. what would be
|abnormal is if the extra rushd stays running for longer than a few
|seconds.
|That means it's trying to access something it can't reach.

Yes most of the PC's have 2 rushd.exe running all of the time, yet appear
rush appears to be running ok. When you start rush there is one, as soon as
a render starts the second appears and stays.

|
|If you're having problems with slowness, check the rushd.log files for
|errors and include them here.

The errors appear to be this:

udp: udp.Receive(): recvfrom(): (10054) (WSA) Connection reset by peer
udp: udp.Receive(): recvfrom(): (10054) (WSA) Connection reset by peer
etc...

On Sun, July 16, 2006 20:14, Dylan Penhale wrote:
> Yes most of the PC's have 2 rushd.exe running all of the time, yet appear
> rush appears to be running ok. When you start rush there is one, as soon
> as a render starts the second appears and stays.

That should actually be OK -- that's just the parent to the renderer.

> The errors appear to be this:
>
> udp: udp.Receive(): recvfrom(): (10054) (WSA) Connection reset by peer
> udp: udp.Receive(): recvfrom(): (10054) (WSA) Connection reset by peer
> etc...

That would mean the daemon was busy doing something else when a UDP message
was sent to the daemon, and by the time the daemon got around to responding,
the program that sent the message went away (ie. someone didn't wait for
the response
and hit ^C, or the program 'timed out' and exited)

I would think there would be other messages that would cause the above.
Send me the /complete/ rushd.log that includes those messages. Send that
to my private email, and I'll respond here with specifics.

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

** NOTE:
**    I will be on vacation July 11th through July 20th.
**    During that time, orders & email response may take over 24 hours.
**