From: Greg Ercolano <erco@(email surpressed)>
Subject: Rush 102.42a9d runs verified to operate normally on Lion (OSX 10.7)
   Date: Wed, 03 Aug 2011 20:30:24 -0400

Rush verified to run normally on Apple's new operating system, Lion (OSX 10.7).

Installs and runs normally.

If there are any caveats, please follow up to this thread
in the rush.general newsgroup/mailing list.

I am having some strangeness after upgrading to Lion.

From Nuke submit script I get
rush: 'rush -submit': select() on connect(): Connection refused

From Maya submit script I get

From Modo submit script I get
rush: 'rush -submit': select() on connect(): Connection refused

Thanks

On 8/3/11 5:30 PM, Greg Ercolano wrote:

Rush verified to run normally on Apple's new operating system, Lion (OSX 10.7).

Installs and runs normally.

If there are any caveats, please follow up to this thread
in the rush.general newsgroup/mailing list.

Thanks

On 4/19/12 4:33 PM, Jeff Jasper wrote:

I am having some strangeness after upgrading to Lion.

 From Nuke submit script I get
rush: 'rush -submit': select() on connect(): Connection refused

 From Maya submit script I get
rush: 'rush -submit': can't open port lock file
'/usr/local/rush/var/nextport': Permission denied

 From Modo submit script I get
rush: 'rush -submit': select() on connect(): Connection refused

I run the installer on all the boxes and get no errors, reboot them all.
Can run one job then get the errors again.

Thanks

On 8/3/11 5:30 PM, Greg Ercolano wrote:

Rush verified to run normally on Apple's new operating system, Lion
(OSX 10.7).

Installs and runs normally.

If there are any caveats, please follow up to this thread
in the rush.general newsgroup/mailing list.

The error is:

Thanks

On 4/19/12 4:38 PM, Jeff Jasper wrote:

Should add all the workstations are running 10.7 and the farm is running
10.7, but the rush queue manager workstation is running 10.5.8, but this
worked fine with the workstations and farm were all running 10.6.

Thanks

On 4/19/12 4:33 PM, Jeff Jasper wrote:

I am having some strangeness after upgrading to Lion.

From Nuke submit script I get
rush: 'rush -submit': select() on connect(): Connection refused

From Maya submit script I get
rush: 'rush -submit': can't open port lock file
'/usr/local/rush/var/nextport': Permission denied

From Modo submit script I get
rush: 'rush -submit': select() on connect(): Connection refused

I run the installer on all the boxes and get no errors, reboot them all.
Can run one job then get the errors again.

Thanks

On 8/3/11 5:30 PM, Greg Ercolano wrote:

Rush verified to run normally on Apple's new operating system, Lion
(OSX 10.7).

Installs and runs normally.

If there are any caveats, please follow up to this thread
in the rush.general newsgroup/mailing list.

On 04/19/12 17:18, Jeff Jasper wrote:
> Just checked if I run the submit scripts from the 10.5.8 queue manager 
> workstation then everything fires off correctly.

	OK, so sounds like you solved the previous problems.

> Also Lion workstations where the user account is hosted on the server 
> work fine, and local accounts that are on the box work fine.
> 
> What doesn't work strangely is a home account that is synchronized with 
> the server so the account is local on the box but sync back to the 
> server. We have a few people setup this way since some apps don't like 
> Lion server homes.

	Hmm, sounds like a different issue.

	If the job submits but doesn't run on the farm,
	hit 'Cpus' in irush for that job, to see if the cpus
	the job is requesting is having trouble running jobs
	as that user on the remote machines.

	A common error is to see in the NOTES field of the
	'Cpus' report is:

		501: unknown uid

	..where '501' might be any numeric value, usually
	representing the UID of the user who submitted the job.
	This error means that uid is not valid on the remote
	machines, so rush can't run the renders as that user.

	If you get that error, the fix is to make sure that user
	has an account on all the render nodes with that same UID.
	(It's important to have consistent uids for accounts)

	Some companies prefer to force all renders to run as
	a particular user, such as a 'render' user with some
	fixed uid/gid. (To do that, you'd set the forceuid/forcegid
	values in the rush.conf file)

	Otherwise, please try to follow up with error messages from
	the Cpus report, Frames report, or the rushd.log file, as
	it should be indicating the error in one of those locations.

> So we have a viable workaround. Only change I am seeing on all 
> workstations since the Lion upgrade is the Modo submit script is 
> throwing up an error at startup. You can run it fine still after 
> bypassing the error screen.
> 
> The error is:
> input: /Network/Servers/"serverhostname"/"users home 
> directory"/.rush/.submit-modo-last: Line 1: unknown field '####ModoCommands'

	Hmm, sounds like some odd text is getting into
	the history file that keeps track of your last submission.

	Has the script been customized at all, or is there
	anything unusual in how the submit script is invoked?
	(ie. invoked by another script that tells the submit script
	what the default options should be?)

-- 
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)

We are all good now! yeah!

On 4/19/12 5:35 PM, Greg Ercolano wrote:

On 04/19/12 17:18, Jeff Jasper wrote:

Just checked if I run the submit scripts from the 10.5.8 queue manager
workstation then everything fires off correctly.

	OK, so sounds like you solved the previous problems.

Also Lion workstations where the user account is hosted on the server
work fine, and local accounts that are on the box work fine.

What doesn't work strangely is a home account that is synchronized with
the server so the account is local on the box but sync back to the
server. We have a few people setup this way since some apps don't like
Lion server homes.

	Hmm, sounds like a different issue.

	If the job submits but doesn't run on the farm,
	hit 'Cpus' in irush for that job, to see if the cpus
	the job is requesting is having trouble running jobs
	as that user on the remote machines.

	A common error is to see in the NOTES field of the
	'Cpus' report is:

		501: unknown uid

	..where '501' might be any numeric value, usually
	representing the UID of the user who submitted the job.
	This error means that uid is not valid on the remote
	machines, so rush can't run the renders as that user.

	If you get that error, the fix is to make sure that user
	has an account on all the render nodes with that same UID.
	(It's important to have consistent uids for accounts)

	Some companies prefer to force all renders to run as
	a particular user, such as a 'render' user with some
	fixed uid/gid. (To do that, you'd set the forceuid/forcegid
	values in the rush.conf file)

	Otherwise, please try to follow up with error messages from
	the Cpus report, Frames report, or the rushd.log file, as
	it should be indicating the error in one of those locations.

So we have a viable workaround. Only change I am seeing on all
workstations since the Lion upgrade is the Modo submit script is
throwing up an error at startup. You can run it fine still after
bypassing the error screen.

The error is:
input: /Network/Servers/"serverhostname"/"users home
directory"/.rush/.submit-modo-last: Line 1: unknown field '####ModoCommands'

	Hmm, sounds like some odd text is getting into
	the history file that keeps track of your last submission.

	Has the script been customized at all, or is there
	anything unusual in how the submit script is invoked?
	(ie. invoked by another script that tells the submit script
	what the default options should be?)

Thanks,
Jeff

On 04/19/12 16:33, Jeff Jasper wrote:
> I am having some strangeness after upgrading to Lion.
> 
>  From Nuke submit script I get
> rush: 'rush -submit': select() on connect(): Connection refused

	Right, sounds like the daemon isn't running.

>  From Maya submit script I get
> rush: 'rush -submit': can't open port lock file 
> '/usr/local/rush/var/nextport': Permission denied

	This probably means /usr/local/rush/bin/rush and /usr/local/rush/bin/rushd
	are not chown 0:0/chmod 4755.

	Since this is normally done by the install script, I can only think
	somehow the install script wasn't actually run here, though you seem
	to indicate you did.

	Check by running:

ls -la /usr/local/rush/bin/{rush,rushd}

	..see if both are owned by root and perms are rwsr-xr-x
	(note the 's' is important in the perms)

> I run the installer on all the boxes and get no errors, reboot them all. 
> Can run one job then get the errors again.

	Is there anything interesting in the /usr/local/rush/var/rushd.log file?

-- 
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)