DISCLAIMER: This is a continuing series detailing the painful story of a DIY render farm build. It is terribly technics and
somewhat frustrating. Those who are unprepared for such “entertainment” are advised to ignore these posts.
Let’s try this again. With the fresh tarball and everything cleaned out for the umpteenth time, I went back at it.
- Created the syscntrl.config for the directory /private/etc. This is supposed to help with shared memory on Darwin systems and is detailed in the Dr. Queue READ ME file.
- Changed permissions on the /tmp directory so it can be seen.
- Restarted for the syscntrl.conf file so that the shared memory takes effect.
- Eureka!
The Activity Monitor confirmed that “master.Darwin.fat” was running! Now what? The graphical interface, drqman, was not running. So I went to the Dr. Queue 10.5 setup page to double check.
- Environment variables (okay)
- /etc/profile (okay)
- master.conf (okay)
But when I tried to launch drqman I got “cannot be wrapped” again.
The log files pointed to a bash shell script called “shlib” but I could not make head or tail of it. I also do not know bash to save my life. Bash is a Unix shell, which means it’s a set of commands for Unix operating systems. This was now the third or fourth new computer language I do not know that I was trying to figure out.
The error log referred to “line 10,” of shlib.sh – not that line 10 made any sense when I looked at it, nor did I know which line was line 10… do they count comment lines?
The Dr. Queue wiki, which I must admit at this late juncture is really quite far from helpful, was my refuge once again – perhaps this was pure superstition at this point. It did suggest these steps:
- GTK2
- scons
- and “swig.”
I had no idea what “swig” was, but I installed the port anyway. It was not going to hurt if swig was never invoked. Later I found that swig means “Simplified Wrapper and Interface Generator.” So it probably was what I was looking for, considering the error I got said that drqman “could not be wrapped.”
When I now dragged “drqman.Darwin.fat” to the terminal it got a new error, this time looking for “libpng12.0.dylib.” So I went to install that port – here we go again! I found an archived libpng12 on the libpng project page. Building the Darwin version was fairly straightforward. Would I get a .dylib that I could manually installed to /opt? Wow that sentence barely made any sense – this alphabet soup was starting to become second nature. I still barely understood what was going on, but the picture was starting to clear up.
But sadly, libpng1251 crapped out when it did not find an already compiled lib12.12.dylib. I give up. I’m about to use a cracked copy of Deadline… at least I know that works. But the prospect of using a software crack on University equipment, and in an educational context no less, seemed more than a bit ethically challenged. There had to be another answer. This was all terribly frustrating, and my faith in Dr. Queue was waning.
I had a brief flirtation with Xgrid, which is a distributed computer system that Apple maintained for years – not that most users would know about it. I certainly did not. Sadly, research into it convinced me that this distributed computer system would probably not work so well for rendering jobs. Big math, maybe, but not as a render farm. This was a big drag since Xgrid is built into OS X… Support for it had lately dropped, though, and nothing has replaced it.
At least I had the Dr. Queue master running if not the GUI. How could I submit jobs with only a command line interface? Ugh – it looked complicated. I certainly wanted a GUI. So I read up and found out that Dr. Queue had a Ruby-on-Rails front-end called “Dr. Keewee.” This would involve submitting jobs and checking on the render farm via browser instead of a dedicated front-end program. How civilized!
So, if not the X11 “drqman” interface, then would the Ruby-based interface work? I had to find out.
-
sudo port install Ruby - An immediate dead end – wait, there are Ruby dependencies???