JeffJournal

Several cool things happened yesterday.

• I re-released PSR
• Brian re-released inilib (ok, that was actually 2-3 days ago)
• My sister got engaged (no URL available :-)

PSR is the Password Storage and Retrieval system that we use with OpenPBS to get AFS authentication with PBS jobs.

We've had problems with our installation of PBS over the last several months (ever since we upgraded to OpenPBS, actually). It turns out that one of the components of PBS, the Mom (a daemon that runs on each compute node and manages the user jobs that are launched on it) was at fault.

Actually, it was our patches to the Mom that were at fault. We had to patch the Mom to include bits to launch some PSR kinds of things (first, a program to get an AFS token, second, a program to "shepherd" the user's job and re-up the AFS token before it expires. Doing this allows a user's job to run for much longer than the life of their token -- their token is magically renewed for them for the entire life of their job).

We used the popen() call to invoke these two commands. Unfortunately, we didn't think that popen() would have the child process inherit the open file descriptors from the parent. But it does. Doh!!

Specifically, the Mom has multiple sockets open, including one that it is listen()ing on. To make a long story short, having multiple processes open sharing the same socket is a Bad Thing, and it caused Ickyness in PBS's runtime because it typically disrupted PBS's internal protocols.

Adding the following code to the beginning of the PSR executables solved the problem:

for (i = 3; i < sizeof(fd_set) * 8; ++i)
    close(i);

However, I still think that this is not perfect -- not knowing the internals of the Mom, I think it is still possible to get a race condition where Badness can occur. This can happen if the PSR executable is launched and them some Event happens on the socket before the PSR executable is able to close it. I think the real solution is to make the sockets be close-on-exec in the Mom, but I'm not sure. I've mailed the PBS guys to see what they think.

If you don't already use inilib, you need to. It will save your life! I classify it in the same category as the STL -- you could write something to do the same thing, but why?

inilib is a C++ library that reads and writes .ini files. While this in itself is unremarkable, its cool aspects include:

• Simple 2D array-like accessors. For example:
  foo["section"]["key_name"] = keyvalue;

• Small API; easy to remember and use
• Automatic write-upon-destruction semantics (if desired)
• Script-like automatic type conversion semantics. This is truly cool. By abusing some of the properties of C++ on the back end, we can do things like this:

    int i = 37;
    foo["section"]["some_integer_key"] = i;
    string s = "1000";
    foo["section"]["some_integer_key"] = s;
    i = foo["section"]["some_integer_key"];
    // i now equals 1000 

  More to the point, you can use the inilib objects like Perl or PHP objects -- all the type conversions are automatic and safe. This is utterly cool.
  

So anyway, go start using inilib. You'd be surprised how often you want to save a config file from your program; inilib just works.

My sister got engaged last night. It was a typical dinner-romantic-walk kind of proposal, but I'm sure that Alan delivered it with style. Needless to say, Terry accepted. Woo hoo! So we'll have another Squyres wedding in the next 1-2 years. Alan's a good guy; I think he'll make a great addition to the family. Now we get to meet his family (who all live in Indiana, not too far from ND, I might add!).

Rock on!