Is there a way to get the Deadline slave process to close gracefully when stopping the Deadline launcher service? We’re experimenting with running the service on our idle lab machines, so that when a user logs out, the launcher service starts and the machine becomes available for rendering. However, we’re running into an issue where, when a user logs back in, the launcher service stops but the slave process does not. The only way we’ve found around it is to kill the slave process forcefully, which causes the slave to show up as stalled rather than offline. Is there a command or some other way to stop the slave process gracefully?
We tried running that command as part of a script that shuts down the launcher service, then runs “deadlineslave.exe -s,” but it didn’t shut down gracefully; the slave timed out and showed up as stalled. Is there a specific order that we should be running these commands in? That is, does the slave process need to be stopped before the launcher service?
That’s strange… I just tested this here and it worked fine. Can you try this again (just from the command prompt, as opposed to your script), and if the slave is killed again, can you send us the slave log from that session? You can find the log folder by opening up the Monitor and selecting Help -> Explore Log Folder. I just want to check if the slave is receiving the command to shutdown or not.
It looks like the issue is with the credentials the Deadline shutdown command is run under. When a user logs out of a workstation, we have the Deadline launcher service launch with specific login credentials, but when a user logs in, the “deadlineslave.exe -s” command to stop the slave process runs with the credentials of whoever is logging in. The command kills the slave, but it only kills it cleanly if it’s run with the same login credentials as the launcher service was run with. Unfortunately, we can’t run the command with those login credentials without saving the password in clear text, which is a security issue.
Is there a way to modify the Deadline launcher service to cleanly kill the slave process when the service is stopped? Or is there another solution?
You could try running deadlinecommand.exe to send a command to the launcher which tells it to stop the running slave (which is the same as using the Remote Control menu in the Monitor), but I’m wondering if you’ll run into the same problem. It’s worth a try though. Here is the command:
Of course, replace [MACHINE_NAME] with the name of the local machine (which your script should be able to pull from the environment). There is also a StopSlave command, but ForceStopSlave would kill the slave if it doesn’t respond to the shutdown command (which is the same thing “deadlineslave.exe -s” does).
Forgive me for poking such an old thread like this, but I am trying to configure the service now and have it almost working so have turned to the docs and forums to get the final mile…
All Windows environment
I can get the service installed and on restart, it runs and joins the farm as render user - great.
I then want to logon as other_user and have this setup in a .bat file to do as I like :
Still good so far, it gracefully shuts down and the other_user can run Launcher, Slave, Monitor, etc.
Then I need to logout as other_user and get the service to “take over” again. I have tried different things here but nothing is working thus far - is there an updated guide for this workflow?
I could ask all the users to reboot when they leave but wanted to see if logout could work as a safety net.
So, the Deadline Launcher nowadays is really good at stopping the Slave when it closes. You could just stop and start the Deadline Launcher Service when the user logs in/out. Would that hit what you wanted?
Give that a try manually (using the services snap in), and if it does what you want I can look into the exact sc commands you’d need to use.
Yes, that sounds great in theory - I just started testing the process.
When I manually kill the service, it does not restart on reboot even though the Properties say Automatic for Startup type… Weird…
I guess it has some kind of “state” memory stored somewhere.
I’ll keep poking at this path and let you know what I learn - thanks again!
