6.2 auth errors, failure get get pool list

[iloura]

Hi

I’ve just rolled back to 6.1 from 6.2.0.32 (after upgrading last week to solve pulse seeming to wipe out our group and pool assignments) due to issues we’ve not seen before with deadline that was affecting both renders on the farm and submissions on the workstations (win 7 64).

Workstation errors would manifest as this sort of error on nuke (7) submission:

• There are no slaves in the ‘Error: Could not read the dbConnext.xml file for the given repostory path “\deadlineserver\deadline_repository\6” because:’ pool. If this pool does not exist, the job will be submitted to the ‘none’ pool.
• There are no slaves in the 'Error: Could not read the dbConnext.xml file for the given repostory path

(I’m assuming that it is just a typo as dbConnext rather than dbConnect (and the repostory), we did try duplicating that file just in case )

And on the slave end:

Report Date/Time Report Type Slave Name Task ID Frames Title Wasted Time
2014/08/31 16:02:35 Error SIMMER58-01 (no task) (no task) Could not find plugin named “Nuke”, path does not exist: \deadlineserver\deadline_repository\6\plugins\Nuke 00:00:00:00

which might contain:

Error occurred while writing report log: Logon failure: unknown user name or bad password.
(System.IO.IOException)

Has anyone else seen this? The feeling from IT is that it’s the use of the UNC name for the repository as we changed one user who was having submission issues to a mapped path and they seemed fine after that. We’ve been using UNC for a long time now.

I’ve seen the logon failure legitimately when the user was actually locked out, in this case the user is fine.

The errors appeared the same day we upgraded to 6.2. Pretty much every rendering job is generating a least a couple of them, though the auto retry means that it went mostly unnoticed for the first few days - the workstation submission problems are somewhat more noticable.

thanks,
grant

[rrussell]

Just to confirm, you only saw this behavior after upgrading to 6.2, and after rolling back to 6.1, the issues went away?

If so, that’s really strange. The Deadline 6 repository installer doesn’t muck with any permissions, and I can’t think of any reason why using a mapped drive would “fix” the issue…

On the machines were submission would fail, were they able to launch the Monitor on their machine? If submitting fails because dbConnect.xml can’t be found (we’ll fix that typo by the way), then the Monitor should fail to start for the same reason.

Cheers,
Ryan

[iloura]

Ok, I can now confirm that this is entirely internal to us - I guess there must be some change between 6.1 and 6.2 since we had a change in error reporting:

One of our isilon nodes wasn’t correctly authenticating a shared resource - once we cleared that up 6.2 no longer had issues (just moved back to 6.2 20 mins ago, we would have seen errors by now and it is clean).

thanks!
grant