SheepIt Renderfarm on Linux Server
Convert unused CPU time to future render time at night with Systemd and SheepIt
SheepIt is a free, distributed render-farm. You can donate computation-time whenever you don’t need it, receive points for it and then use those points to render your own projects later. It basically allows you to “save up” render time over days, weeks and months and then use it all in one to render your finished projects in mere hours.
It’s Open Source (mostly)! You can use it on Windows, Linux and Mac. It has an easy to use UI for beginners and comprehensive command line interface for more advanced users. It’s completely free and the community support, for example in the Blender Discord is very helpful and admins are active as well.
By it’s very design, SheepIt is a Blender-only rendering farm. You cannot use it to render project files of other projects. Secondly, your files will be distributed to untrusted 3rd-party computers and servers, which could, theoretically, scrape your content.
The SheepIt client doesn’t work with AMD-GPUs on Linux, because of problems with both the open source and proprietary drivers. These issues led to inconsistent results with rendered frames and AMD cards were subsequently disabled.
Scripts are completely disabled for safety reasons and the project’s size and render times are limited, so you have to be careful, when including bake files, for example for fluid dynamics (which you have to bake because you can’t render them unbaked on SheepIt).
You are not allowed to render NSFW content. Their official reason for this is not having age verification and must therefore assume, that there could be minors on the platform. Their policy on nudity is very strict, but the extent to which other age relevant content, like for example third person shooter simulations are allowed, is left ambiguous and for now seems to rely partly on a gentlemen's agreement, to use common sense when deciding which projects to render on SheepIt.
Running the client in command line
Download the client. You only need Java installed. Create an Account on the SheepIt-Renderfarm, go to your Settings and create a new render key, you can also login using your password instead of a token though.
In addition to password and username (login), we need to define the UI (as text only), the cache-directory, the compute method (CPU or GPU) and the maximum memory. The memory we indicate is more of a guideline to the server, so it’s best to have a little buffer between the value we will later set in systemd as a limit and the value in the start parameters.
Projects you are assigned will still, occasionally, use significantly more memory and crash the process. That’s not a big problem, systemd can just restart it and it’s very unlikely we will get the same project/frame assigned twice and even in the unlikely case this happens, the SheepIt-cluster will probably, hopefully, eventually flag it as broken.
Finally we can set a request time, during which we want to accept new frames to render. In this example it set it to
1:00-10:00, accepting jobs only late at night until the late morning hours, during which my server is usually not very busy. Keep in mind that frames render up to 20–60 minutes, depending on the strength of your machine and will finish rendering, if they were accepted before the end of the specified time frame.
You should now try out your script. If everything works well, save the script, mark it as executable and move it to a permanent location before continuing to the next part. The client will automatically run with a high “nice”-value (meaning a low priority), so even if there are some other things running on the server, it’s not immediately a problem. We will also limit CPU time in our systemd-unit in the next paragraph.
Setting up a systemd-unit
A systemd-unit will take care of starting the client for us and limit it’s resource-usage on the server. The options are in order of the example below:
- We want the service to start after the network is available.
- It’s a type simple, meaning the script starts and is not expected to return until it fails or is stopped.
- We want it to run as a specified user, not root, which would be the default if no user is specified.
- We want the unit to have a valid working directory, so the executed script may write caching-files. (You can also just set this to the home directory of the specified user if you want to be lazy.)
- The start command is the absolute path to the executable script we just created.
- We want to limit the memory usage to the value we set in the client’s parameter plus some buffer. If the client goes above this limit, systemd will kill any process associated, with an out-of-memory error (noted in the log as an OOM-kill).
- We want to limit the CPU usage. 100% equals one logical core, I have 8 logical CPU-cores on my server and limit it to 600%, aka 6 logical cores.
- The client already sets a “nice”-value of 19, but it doesn’t hurt also setting it here.
- The client may still crash for some reason, but most notably this happens, because the SheepIt master server misjudged the memory usage and the process is terminated by the OOM-killer. For this reason we use
Restart=Always, to always restart the service. We then use
RestartSecto set limits on how often and how fast the service should attempt to restart.
- Finally we add a
WantedBy=multiuser.target.multiuser-target to tell the systems to start this unit as part of the normal boot. (Or more precisely: The system wants to reach this target and to reach this target it tries to start all services, which are “wanted” by this target.)
Here is the full service file:
Place this file as sheepit.service into
/etc/systemd/user and run
systemctl enable /etc/systemd/user/sheepit.service, to enable it (mark it for start at a reboot) and
systemctl start sheepit, to start it without rebooting.
You can now use
journalctl -u sheepit and
systemctl status sheepit to check the logs and the sate of the service.