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.
I seemed to have the master and one slave talking to each other, but it did not seem as though scripts deployed by the master were actually completed, despite Dr. Queue telling me they were. I tried running a blank script that just said
This showed nothing on the slave machine. I wondered why the scripts were passed to the slave but not acted upon. This was some kind of users and permissions deal, I thought (as it turned out, I was wrong again). In any event, while trolling through the PDC directories, I noticed the “Python” folder. And whereas I was not sure I needed to bother with it, the “setup.py” and “test for a leak.py” scripts did bomb out when run through the terminal. If everything were OK they should execute properly, yes?
I began wondering: should I update Python to 2.4, as suggested in the documentation?
Oops! The Dr. Queue documentation was way out of date. Python was currently at 2.51 on the master machine, but the “real” Python is up to version 3.x something. What to do? I began to consider Dr. Keewee again, because that is Python-based. I could run it and see if it started up, thereby telling me if I were OK with Python. I had not attempted Dr. Keewee in some time, and I had forgotten to re-read this log to find out where I had stopped with it.
But trying Dr. Keewee again failed – a bust. My version 2.5 of Python might have been too old? Python had apparently diverged, with version 2.x and 3.x still developing forward. I figured I should stick with 2.x since there were some apparently major changes. The latest was version 2.7.9 and there was a 32-bit PPC installer, so I grabbed it for the PDC Mac Mini.
Then I installed the Python bindings for Dr. Keewee on Cyclops. I never thought it would actually help.
It didn’t. This was another dead end. The Dr. Keewee Python bindings are kind of a mess, and would involve some of the dependency nightmares I’ve already had on this machine. For some reason I had forgotten that the other two front-ends for Dr. Queue had been something of a pain in the ass. Or maybe I was just feeling confident and figured I could now get them to work. It occurred to me that these packages might work better on a non-PPC machine. And that may have been true, but I was off track – none of this seemed to address my current problem. Onward! I still had other fish to fry!
I attempted a simple bash script that printed out “test script.”
echo “test script"
If run on the slave terminal locally, it worked fine, and I saw the terminal echo what I had asked it to. If sent as a Dr. Queue job, I saw no evidence of it working.
Why not? This was the central issue, and solving it would go a ing way towards success. Dr. Queue was able to send the “job” but the slaves did not seem to be executing it. Was no task sent? How could I verify?