Slave no longer starts (6.2.1.50)

I have a slave that stalled out, and now it can no longer be started. I have tried manually starting it via remote control, as well as restarting both the launcher service and the machine.

When I run the launcher in a terminal, I get this:

[code]bash-4.2$ /usr/local/Thinkbox/Deadline6/bin/deadlinelauncher -nogui
Launching Slave:
Launcher Thread - Launcher thread initializing…
Updating Repository options

  • Remote Administration: enabled
  • Automatic Updates: disabled
    Launcher Thread - Remote administration is enabled
    Launcher Thread - Launcher thread listening on port 17060
    Deadline Slave 6.2 [v6.2.1.50 R (b43a54430)]
    Stacktrace:

at Deadline.Configuration.Plugins.PluginManager…ctor () <0x00077>
at Deadline.Configuration.Plugins.PluginManager.GetInstance () <0x00047>
at DeadlineSlave.DeadlineSlaveApp.Main (string[]) <0x00eb7>
at (wrapper runtime-invoke) .runtime_invoke_int_object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

Updating Repository options

  • Remote Administration: enabled
  • Automatic Updates: disabled[/code]

Help? I at least need to know how to get the slave running again, as I have a feeling this will not only affect this one machine.

Hello,

I am told that one possible option here is to delete all files in the location ‘/var/lib/Thinkbox/’ and then restart, and try to launch it again.

I don’t think that would help in this case. The directory trees between this node and one that runs fine are identical down to the permissions on everything and the contents of their deadline.ini files.

I triggered a client reinstall via puppet and the slave seems to be running normally again. I really don’t understand how a running slave could corrupt its own installation.

Sadly sometimes files get written wrong or errors happen for a number of possible reasons, from hardware(bad sectors, failing drives, etc) to files just not getting saving right. This is why we have some aspects of Deadline that can be deleted, and which will be recreated upon relaunch. I am glad, though, that the reinstall seems to have had some luck.

Just to be clear, I didn’t touch anything in /var/lib/Thinkbox, and nothing in there has changed as far as file content goes.

I would assume, then, that the reinstall made changes there, or that making that change was not needed.