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.
In which I destroy everything.
I installed a blank drive called “Lucifer” (it matches JHVH-1 and keeps with my Christian eschatology theme) to be the common drive for scripts, logs, temp files, etc. Now all slaves, including JHVH-1 itself, will have the same pathnames, namely /Volumes/Lucifer/.
Still struggling with Dr. Queue, I started from scratch.
- Installed MacPorts
- Installed Xcode and Xcode Command Line Tools
Then,
port install scons sudo port install gtk2
Then…
KERNEL PANIC FAIL on JHVH-! The whole shebang was somehow completely goofed up. Holy cats, I destroyed it! This does explain the weird sudo behavior I experienced last time. I must have really borked up some important settings.
Ah well, start from scratch, and I really mean from scratch – from a bare drive with nothing on it,
Luckily I could image the slave drive and start with that.
- Re-imaged from slave node
- Set up new account, turned off all annoying Mac stuff like
- notifications.
- dumb desktop
- “All my Files” – seriously, who would use that?
- etc.
- Set the new JHVH-1 to a hard IP of 10.1.1.1
- Installed Xcode and Xcode Command Line Tools
- Installed MacPorts
- Downloaded a fresh copy of the last continuous build of Dr. Queue
- Set environment variables – both right now in the Terminal and also set up a shell script to set them on login
- “error getting shared memory; invalid argument” – Dr. Queue has some kind of crazy shared memory issue on Macs which requires a few lines added to /etc/syscntrl.conf, which does not seem to exist just yet. I’m perhaps looking in the wrong version of /etc.
- Ran the included script “install_launchd.sh” found in the Dr. Queue distribution. This seems to have set the syscntrl.conf file properly.
- Well! That seemed to perk everything up right away. Running the master from the Terminal gave me instant success. Twelve master processes were running!
- The slave works immediately. So restarting everything seems to have done the trick.
The issue now is how to get a front-end working. So at this point I had most of the farm back, but without a proper front-end I’d either have to do everything by command-line (ugh) and write scripts I could safely debug, or get cracking on the front-ends.
If you’ll remember, the front-end is part of what I am trying to fix with Render Farm 2.0. The old drqman front-end, running under X11, is fine for local use, and better than nothing. But it could not be accessed remotely, and I could not check the status of anything while I was away. This is not so great for a farm that is about 40 miles from my house.
Thus I went back to drqman.
Attempting to run drqman from the command-line gave me errors. Drqman needs GTK2. So, off to build GTK2.
sudo port install gtk2
Humming along, the gtk2 build seems to have installed, but when drqman was run from the command-line it bombed out. Some quick Googling revealed that gtk2 may have to be built with some flags turned on, namely for Universal binaries and for X-11, thus,
sudo port install gtk2 -x11 +universal
And this build went humming along, taking quite some time.
Once built, drqman accepted gtk2 just fine, but now asked for a dylib for libpng12.
sudo port install libpng
But it still wants the library “libpng12.dylib.” I’m pretty sure it would not want the one built for the PPC Mac Mini. Grrr.
It makes me want to use another front-end.