I have a Maya 2014 deployment sitting on the network, and I’m trying to make a job that will deploy it gradually for us. I am creating a “CommandScriptSubmission” with the following command:
The job works fine, it installs Maya and everything. The problem is that it doesn’t “complete” frames after setup.exe is finished running. Is this a bug or am I doing it wrong?
Do you mean that the frame ends up “rendering” indefinitely, or does it get requeued after each run?
If it’s the former, do you know if the Setup.exe process is exiting after Maya has been installed? All the command script plugin does is wait for the executable to exit, so if Setup.exe never exits, that would explain the problem.
That’s correct. The status remains “Rendering” well past the point after Maya is successfully installed, and Setup.exe is no longer present. I’m doing it again now just as a sanity check, but when I looked yesterday I saw no setup.exe and the tasks had been rendering for over an hour on each machine, but the install really took around 20-25 minutes.
Strange. Can you also double check if the slave application on the actual machine is showing if it’s “rendering” or not? Wondering if it might be a display issue in the Monitor only (the Monitor thinks the task is still being rendered, but in reality the slave has moved on).
Yeah, I also checked the local slave, and it is still “rendering” with all of the job data still filled in the fields of the slave. Setup.exe *32 is done and is no longer running. Here are a couple of screenshots, 1 during installation and 1 after it’s complete but the job still keeps “rendering.” I also uploaded a screenshot of the slave log.
I notice that msiexec.exe is running in the Task Manager. Do you know if Setup.exe launches any child processes like msiexec.exe? If it’s child processes are still running, that could explain this behavior.
Another thing to try would be to wrap the Setup.exe command line in a batch file, and try running the batch file through Deadline to see if that makes a difference.
Yeah, I tried the batch file method, but I ran into a snag because the batch file is stored on a linux server and creating a popup message when it runs on the local machines, so it defeats the silent install. The closest I got to a good silent install was with the Command Script method. It did everything just fine but then didn’t complete the task.
Yes I believe you’re right about msiexec. This is installing a large handful of things and I wouldn’t doubt it’s launching child processes. I haven’t really dug that deep into it yet, I was hoping this would be pretty straight forward. I think I have a fix now, we found a registry edit we can do to make the popup from the .bat file stop happening.
Oh yeah, I remember now. The batch file method isn’t working because the batch file exits after the installer finishes with installing Directx, but that’s just the first step. I need a method of doing this that waits for the entire install procedure to finish and then completes. I have thought about putting a sleep period for about 45 minutes, but this is also not the most ideal scenario.
So you have a .bat file that launches the DX install as a separate process, but needs to wait for it to finish before continuing on. It probably wouldn’t be too hard to write a PowerShell or python script to watch for the DX installer process name, then exits when the process disappears (maybe with some delays on both sides).
In fact, if you’re installing to only Windows machines, it might be best to just use a PowerShell script rather than a .bat script. Then you can build in the process monitoring directly.
Cool thanks for the advice. I’ve never looked into powershell but now I have a good reason. I am noticing that the Maya 2014 deployment procedure is a bit buggy in general, so I’m going to have to really think about it and test it before I figure out the best method. There’s literally dozens of ways this could be handled, and I’ve tried about a dozen of them already. This weekend we left a job on the farm that we set a task timeout on and it worked out pretty well. Instead of a list of completed tasks, we have a list of machines the job “has been marked bad for” which are actually completed installs. A bit backwards, but whatever gets the job done.
