I’m having trouble getting idle detection working on the latest release candidate.
Deadline version 7.0.0.50 RC4 on Ubuntu 12.04
I’d like to be able to use “slave scheduling” in order to get some of our workstations on the farm when they’re idle. So, I’ve set up a group (that’s enabled) to start slaves when they’re idle for 10 minutes. In the slave panel these slaves have “Idle Detection” listed as off. If I set the “Override Idle Detection Settings” for the slaves with similar settings, it shows “Idle Detection” as on in the slave panel. But, my slaves don’t start rendering in either case. What state should I leave the slaves in? Are there any logs that I could check through for this - I don’t see anything pertaining to idle detection in the usual places.
Is the Deadline 7 Launcher running on your machines? It controls the starting and stopping of slaves, and must be running on each machine for Idle Detection to work.
It shouldn’t, and I just confirmed that it works fine here.
Can you open a terminal and navigate to the deadline bin folder (ie: /opt/Thinkbox/Deadline7/bin), and then run this:
./xidlewrapper
This should print out a floating point value, which we use to determine how long it’s been idle for. Just want to make sure it runs on your machine without any problems.
If I ssh in to a machine I’m trying to get renders to run on it segfaults.
I can get it to run when I ssh -X in to the machine.
It’s just clicked that this is the cause of some errors I’ve come across in our syslogs.
Dec 9 18:02:27 molly kernel: [90320.153452] xidle[767]: segfault at 968 ip 00007f3063866ae8 sp 00007fff1e367440 error 4 in libX11.so.6.3.0[7f3063833000+130000]
Dec 9 18:03:28 molly kernel: [90380.577329] xidle[783]: segfault at 968 ip 00007f9f9113fae8 sp 00007fffefee0540 error 4 in libX11.so.6.3.0[7f9f9110c000+130000]
Dec 9 18:04:28 molly kernel: [90440.877916] xidle[800]: segfault at 968 ip 00007f379ef97ae8 sp 00007fff7c0c68c0 error 4 in libX11.so.6.3.0[7f379ef64000+130000]
Dec 9 18:05:28 molly kernel: [90501.198010] xidle[808]: segfault at 968 ip 00007f9a612f5ae8 sp 00007fffc4d9de50 error 4 in libX11.so.6.3.0[7f9a612c2000+130000]
Dec 9 18:06:29 molly kernel: [90561.482830] xidle[818]: segfault at 968 ip 00007f9135b08ae8 sp 00007fff678e6060 error 4 in libX11.so.6.3.0[7f9135ad5000+130000]
Ah, of course. The feature requires X11 to detect idle keyboard and mouse, so it won’t work without it. If the launcher is running in a headless environment, that would explain why it isn’t working.
I’m installing it with the --launcherdaemon option on our renderfarm as well as our workstations. So our launchers start as the root user, as such, they’ll never run with a graphical environment. I’m struggling to see how to make use of this feature in our environment - even though I really want to make use of it.
I could try and get the launcher to startup when a user logs in. Idle detection should work OK then, but it’ll stop working if the user logs out.
What I’m looking to do when I boot a workstation up, is have it available to render on immediately (or shortly afterwards) until someone starts using it, then when the users stops using it (either locking screen to go on lunch, or logging off at the end of the day) it becomes available to render on again.
Am I able to use a custom “xidlewrapper” script if I can work out something that works better for us?
Please feel free to move this topic to the discussion forum if you feel that’s a better place for it.
You could. All we expect is for the script to print out the idle time in seconds as a floating point value. If you do figure out something that works better for you guys, feel free to share it! Maybe others could benefit as well (and maybe it would be something we could look at doing out of the box in the future).
It means the launcher starts up as root in an Xsession, which is what I’m looking for, and it seems to detect “idleness” correctly - I still need to test this more thoroughly though.
Just to let you know we fixed a similar issue with xidle detection in headless mode in our upcoming v7 patch release. A Release Candidate of this release can be found here: viewtopic.php?f=204&t=12877
I’ve just got back in to looking at idle detection after upgrading to version 7.0.2.3 & this method doesn’t seem to be working any more, in fact I can’t seem to get it to work under any circumstance. I’ve tried running the launcher as root using the method I describe below & I’ve even tried running the launcher as myself after logging in. I’ve tried using slave scheduling & I’ve tried using the slave overrides. The slave will not start up automatically - if I start it manually, it will not stop the slave when I start using the machine. Do you have any suggestions as to how I would start to troubleshoot this?
After upgrading to 7.0.2.3, did you update the xidlewrapper script with your changes on your machines? When your machines were upgraded to 7.0.2.3 from the previous version, this would have wiped out your changes.
I didn’t end up changing anything in the xidlewrapper script. I only changed the way the launcher was started so that it was in an xsession run by root.
Here’s the log - doesn’t seem to pick up that it shoud have idle detection on at all.
2015-02-13 15:28:48: BEGIN - anson\root
2015-02-13 15:28:48: Deadline Launcher 7.0 [v7.0.2.3 R (24b5c0a7f)]
2015-02-13 15:28:48: Launcher Thread - Launcher thread initializing…
2015-02-13 15:28:48: Launcher Thread - Launcher thread listening on port 17070
2015-02-13 15:28:51: Auto Configuration: Picking configuration based on: anson / 10.0.0.147
2015-02-13 15:28:51: Auto Configuration: Match found for rule workstations (HostnameRegex)
2015-02-13 15:28:51: Auto Configuration: A ruleset has been found
2015-02-13 15:28:51: Auto Configuration: Set License Server to ‘@delany’
2015-02-13 15:28:51: Auto Configuration: Set Launch Slave At Startup value to ‘false’
2015-02-13 15:28:51: Auto Configuration: Set Restart Stalled Slave value to ‘False’
2015-02-13 15:28:51: Launcher Thread - Remote Administration is now enabled
2015-02-13 15:28:51: Launcher Thread - Automatic Updates is now enabled
2015-02-13 15:33:53: Auto Configuration: Set License Server to ‘@delany’
2015-02-13 15:33:53: Auto Configuration: Set Restart Stalled Slave value to ‘False’
2015-02-13 15:38:53: Auto Configuration: Set License Server to ‘@delany’
2015-02-13 15:38:53: Auto Configuration: Set Restart Stalled Slave value to ‘False’
2015-02-13 15:43:54: Auto Configuration: Set License Server to ‘@delany’
I’ve tried logging in & starting the launcher manually myself (after stopping the one that automatically runs as root) just to see if it was something else to so with the way I was launching it, but I get the same results.
Thanks for checking. There aren’t any errors, which leads me to believe that the Launcher can check if the machine is idle just fine. So the next place to look would be the actual idle detection settings. Can you post screen shots of the following?
Your global slave scheduling settings, which you can access from the Tools menu in the Monitor while in super user mode.
The Idle Detection override settings in the slave settings for the slave on your machine. You can find by right-clicking on your slave in the slave list in the Monitor while in super user mode, and selecting Modify Slave Properties. Then select the Idle Detection page.
I think we figured out the problem. The xidle binary wasn’t returning the proper exit code, so Deadline assumed there was an error running it. This will be fixed in 7.1 beta 3.
In the meantime, try extracting the attached file to the Deadline bin folder on your machine (/opt/Thinkbox/Deadline7/bin) to see if it works properly. You can make a backup of the original xidle file in that folder, just in case. The attached file will overwrite the existing xidle file in the folder, and then you can restart the launcher and see if it starts up your slave properly.
