AWS Thinkbox Discussion Forums

Deadline 10 - Powermanagement BAT file

Hello,

We are running pulse on an extra server for our power mangement. Since deadline 10 our BAT file which pulse should start is not working anymore.
Have there been any changes or are some options i should be aware of because it was working on deadline 9 without any problems.

If i´m starting my bat file by hand it works like a charm.
I already updated deadline 10 a few weeks ago to the version below without changes.

Deadline 10.0.12.1
Windows Server 2012 R2

thanks,

alex

Are there any permissions issues running it as the deadline user? do you get any error messages?

We haven’t made any changes to that aspect of power management as far as I’m aware.

If you enable ‘Pulse verbose logging’ in the ‘Configure Repository’ settings, does it show anything as far as trying to run your script? Also, does your script output anything? Occasionally, I’ll put a little “echo %TIME% > c:\some\folder\last_run.txt” to make sure the problem isn’t from command I’m running. Ant’s right in that if Pulse is running under a different user account there may be parts failing.

Hello,

thanks for the suggestions, after some more testing here are my new awarenesses.

the startup scripts are working without problems but the shutdown scripts are not working even if i´m putting in something like this:

ping -n 10 127.0.0.1

the slaves are shuting down but the machine didn´t shut down.

The logfile is writing out something like this:
2018-04-17 11:07:36: Power Management - Idle Shutdown: Running command on idle slave RenderSlave01 because it has been idle for longer than 2 minutes
2018-04-17 11:07:48: Power Management: No idle shutdown notification address specified in Repository Options - cannot send notification

The pulse server is running under windows 2012 r2 with user account “Administrator” and the renderslaves are runnning under windows 10 and “Admin”.

The echo output does not write into the txt file so pulse or deadline is not executing the shutdown bat.

echo %TIME% > c:\last_run.txt
ping -n 10 127.0.0.1

thanks,

alex

For this, are the Slaves actually closing? We’re up against a problem at the moment where the Slaves are being asked to close but they’re locking on a call to Python. Can you log into the machines and check?

The script run should override the stopping of the Slave at all… The shutdown script is also run on the render nodes. Is the script copied to the path your provided, but on every render node?

Hello,

The slaves are really shuting down so there is nothing in the taskmanager beside the deadlinelauncher.exe.

The shut down script is on a server where every one has access.(\env\Deadline\PowerManagment_Scripts\ipmiutil\PowerOFF.bat)

The thing is if we are using the internal shutdown Command from deadline everything is working, just the run command mode is not working for us.

I´ve upgraded today to 10.0.14.1 but no changes.

thanks,

alex

And the render nodes can power themselves off by running “PowerOFF.bat” from that location? The fact that it’s not running is unusual.

The test script might be failing to write output because it’s not allowed to write to the root of the C: drive by default:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\me>echo > c:\test.txt
Access is denied.

Hello,

Yes when i´m starting the script “PowerOFF.bat” from this location from any our workstation or windows 2012 r2 server over cmd or windows explorer they shutdown.

the echo works when i´m starting it manually or over cmd i also could put it to an other location for example D: and it won´t work by deadline.

cheers,

alex

Hello,

I’m just curious, if you make a command line job to run that script on a specific machine, does it execute properly? Is there any indication in the Launcher logs of the command being received?

Dwight’s suggestion would be to check permissions for the Slave and by extension the Launcher.

I think at this point we need to test this… I’ll see what we can do on that.

Privacy | Site terms | Cookie preferences