We’re exploring the idea of switching deadline launcher to a service on our workstations so we can use login/logout scripts to automatically start the slave when a user logs out, and then stop it when they log back in. Starting the slave with “deadlinelauncher.exe -slave” seems to work fine, but if I run “deadlinelauncher.exe -shutdown” to stop the slave, it doesn’t seem to do anything. I can’t even find any indication in the logs that it happened. Is this the proper way to stop a slave from the local machine when it’s running in service mode, or is there a better way?
Thanks.
Darren
I should have mentioned that this is in beta 18.
Hey Darren,
Try using “deadlineslave.exe -shutdown” to stop the slave. The “deadlinelauncher.exe -shutdown” method doesn’t shut down the launcher when it’s running as a service.
Cheers,
Thanks, looks like that works!
Just so you know, running “deadlinelauncher.exe -help” currently shows the following beside the shutdown option:
Specify this flag to shutdown all running slaves on this machine
Good ol’ copy & paste errors… 
We’ll fix the help instructions for beta 19.
Thanks!
I’ve been looking into this more today, and it looks like “deadlineslave.exe -shutdown” only works when run from the same user that the service and slave are running as. When run from another user (even if it’s an admin user), nothing happens. Is this intentional, or is it a bug?
Also, I’ve been noticing some issues with starting and stopping the slave from deadline monitor when launcher is running in service mode. As far as I can tell, I’m able to start and stop the slave from the monitor when logged in as any user, as long as I’m running monitor on the same machine as the slave I’m trying to start or stop. When I try to do this from another machine, nothing seems to happen. I can’t find any related log entries either. Do you have any idea what could be causing this?
Thanks.
Darren
That’s currently by design. I wonder if that’s a restriction we should look at changing…
You can open up the Remote Commands panel to check the results of the commands. Hopefully they contain some useful info. In beta 19, we will be popping up the Remote Command panel automatically if it isn’t already open.
Cheers,
It’s obviously not a show stopper, but it would be useful if we could have any logged in user start and stop the local slave while in service mode. We were just looking to simplify things for users so all they have to do to get their machine in render mode is to log out of windows at the end of the day. If there are cases where this behavior isn’t wanted, maybe it could be configured in repository options or something?
Thanks, that gave me the info I needed to figure out that one. It turned out that I was getting a “connection attempt failed” error because I forgot to disable the Windows firewall on the VM I was testing with. Sorry to bother you with that one…
I’ll put it on the wish list to see if we can remove that restriction for 6.1. Worst case, it might have to wait until 7.0 if it ends up being a breaking change. Glad to hear it’s not a show stopper at the moment.
Cheers,
Cool, thanks!
While we’re talking about service related things for the wish list, one thing that would be super convenient would be to retain the deadline launcher and slave tray icons for logged in users even when the launcher is in service mode. I don’t know if that’s even a possibility, but I noticed that UltraVNC seems to have a way to do that - it can be managed from a tray icon even when it’s running in service mode. I was just looking into their setup a bit, and as far as I can tell, I think the service monitors whether a user is logged in, and if they are, it launches a second helper process that deals with the tray icon. If I switch users and come back, the tray icon and the second process take a few seconds to come back, so it must just do a periodic check.
This is just wish list stuff, but I thought I’d bring it up anyway.
Yeah, that’s been on our wishlist for a while now.
We currently have it targeting 6.1, but it’s probably lower priority on that list. Hopefully we get to it sooner rather than later.
Cheers,