I just ran this monitor command on a bunch of machines, (by accident, * everyone loves me right now) and for the most 90% of the machines restarted immediately after wards.
So my question is, what requirements would stop a machine from restarted right away?
we had a few folks who’s machine took a good 20-40 min after to finally restart.
The silly answer is if the Slave is currently working on a task.
One thing, the back-and-forth on comms is kind of “peculiar”. It works like this:
The Launcher gets the command
The Launcher reads all of the Slave ini files (in “C:\ProgramData\Thinkbox\Deadline10\slaves” on Windows) to find the client comm port
For each one, it sends the command to close when it’s complete, probably doesn’t care if the message got through.
The Launcher sits around waiting for all the Slaves’ listening sockets to close off
The Launcher tells the machine to shut down.
So, best guess at the moment is that the Launcher read an old Slave ini file, saw that the (now stale and invalid) port was in use (it can’t tell that it was something that wasn’t the Slave) and sat there until it saw the port close (probably an old client TCP session from a web browser). From there it shut the machine down.
That’s my guess anywhoo. Feel free to go dig up the Launcher log and take a look. It should say over and over “waiting for the Slave to exit”.