A new -shutdown <time> option has been created to specify the time when the client will stop asking for new jobs, will finish uploading the frames in the upload queue and will shutdown the computer. The time argument can have two different formats: an absolute date & time in the format yyyy-MM-ddThh:mm:ss (24h format) or a relative time in the format +m where m is the number of minutes from now.
The user can also select the shutdown-mode, where "wait" will wait for all the processes (render + pending uploads) to finish and "hard" will cancel all the pending jobs and will initiate the computer shutdown.
The text UI gets quite messy during the render process, as it takes at least one extra line of the screen per second. This PR fixes that issue and also shows an ASCII bar to show the render progress.
As the value of the askForRendererKill flag is set right after the return of the kill process, under some particular memory and system load circumstances, a race condition occurs and the rendering process in the main thread is closed faster than the process.destroy() returns the control to the thread the called the OS.getOS().kill(process.getProcess()) method. If that condition occurs, the isAskForRendererKill() check returns false (the flag hasn't been set to True in the separate thread) and the execution continues with the frame output check (that doesn't exist as the rendering process was interrupted). The final outcome is a wrong NO_FILE_OUTPUT error instead of the proper RENDERER_KILLED_BY_USER_OVER_TIME.
The fix has been setting the askForRendererKill flag to true before the process is destroyed. If the racing condition occurs, the askForRendererKill will be correctly set.
* Fix: EEVEE renders with CPU instead of GPU in Linux clients
In Linux systems, setting the env LD_LIBRARY_PATH var to point the /lib folder included in the sheepit binary compressed .zip, mandates Blender to swap whatever openGL library is already in use by the OS. Modern GPU drivers install their own optimised version of the OpenGL library and replacing it creates incompatibilities that avoid EEVEE to run.
To detect if Blender already uses the standard OS provided OpenGL library is via _ldd_ Linux command. The execution in a system with OpenGL libraries already in use delivers an output similar to this:
ldd rend.exe
linux-vdso.so.1 (0x00007ffda6bf9000)
...
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fefefe3a000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fefefc30000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007fefefb9c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fefefa4d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fefef85c000)
...
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fefef6e7000)
While a system with no OS OpenGL libraries that requires the shipped default OpenGL lib to work returns this instead:
ldd rend.exe
linux-vdso.so.1 (0x00007ffda6bf9000)
...
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fefefe3a000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fefefc30000)
libGL.so.1 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fefefa4d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fefef85c000)
...
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fefef6e7000)
In the former case, the SheepIt client will set the LD_LIBRARY_PATH env var to point the /lib folder to allow Blender to execute properly.
