New Plan

•November 11, 2010 • Leave a Comment

After discussing my pipe idea with Patrick, we have settled on a new plan.

The main listener process will create a pipe before it forks twice, then the second child will be able to send its pid back to the main process through the pipe.  This pipe will remain open so the child can notify the main process when it is finished.  The main process will ping each of the child listeners when it receives a new connection to see if it is still alive or if it crashed.  The child will also write a pid file to a directory which the main process will browse to determine how many/which children should still be alive.

Getting PIDs of Grandchildren

•November 5, 2010 • Leave a Comment

So after some more thought and talking with a few of the other undergrads I’ve examined several approaches to acquiring the pid of the listener after forking twice.  I thought about having the middle child (after the first fork) exit with the pid of the second child (after the middle child forks), but when the parent receives the exit value of the child it only receives the least significant 8 bits which is not large enough to hold the pid.  I also considered not forking twice and instead making a signal() call to catch the SIGCHLD signal and hand it to a function to gracefully kill the zombie process, but I was doing some reading and it sounds like that isn’t the most portable method.  I briefly considered having the grandchild write its pid to a file that the parent could then read, but that seems much to brutish and has a lot of potential for bugs.

Making the signal() call seems like simplest of these options.

I just had a thought that perhaps calling select() could solve this issue.  It would remove the necessity to fork at all, as all the connections could be processed in the handler.  I want to run this by Patrick and get his opinion before I start attempting to implement it, as it would require some more drastic changes to the code.

Another brain wave!  I could set up a pipe in the middle child connecting the grandchild to parent through which the grandchild could give its pid to the parent.  I’ve never done piping before, but I think it would be the best solution that would require the fewest amount changes to the code and the architecture of the listener.  Again, I want to run this by Patrick first.

Yay! Compiling

•November 2, 2010 • Leave a Comment

I finally got my changes to the daemon to manifest when I ran besctl, so hopefully I can start getting some real stuff done now.

I put the key value pair BES.MaxConnect=10 in bes.conf to keep a limit on the number of connected hosts and read it in with the BESServerHandler.  I had to add a few more private member variables to BESServer handler as well (_maxConnect and _numConnected).

I was looking for the correct place to increment/decrement the _numConnected counter and realized it may be a bit more difficult that I thought to determine when a child dies and it is safe to decrement the counter.  In the handle() function, the program forks twice and the connection is handled in the second child, and the middle child exits.  The way it is currently implimented I know of no way to get the pid of the second child where the connection is actually being handled.

When I’ve written forking programs before, I’ve used signal(SIGCHLD,SIG_IGN) to take care of zombies.  If we use this method here we wouldn’t have to fork twice and we could pass signal() a function handler that could take care of the necessary cleanup when the child finishes processing the connection.

Implimenting New Design

•October 29, 2010 • Leave a Comment

I am attempting to make some modifications to the listener, but I’m a little confused as to how beslistener works.  I see the BESServerHandler and ServerApp classes, but is there a main file (like where those classes are being constructed and uesed?  This stems from my search for a good place to store pids/ports of child listeners.  I’m thinking I will create a file in /var/run (where bes puts its pid file) and store the information there.

I tired un-installing and reinstalling the bes in an attempt to get the besdaemon to manifest the changes I made, but to no avail.  I will have to ask Patrick for some help.

I’m getting frustrated at the lack of time I have to work on this project.  This is the most interesting thing I’m working on this semester and I have very little time to work on it. 😦

Continued Learning

•October 26, 2010 • 2 Comments

The undergrad lab room was locked again today, so I was working at the conference table downstairs.

I read through the listener code today and, as before, enjoyed looking through all the code and making sense of it all.

I was trying to make some simple modifications to make sure I was making the project right and it was a good thing I did.  When I made a few simple changes to the output that shows up when the bes starts and ran make, I did not see the modifications when I started the bes.  Even when I did a distclean and remade the bes.

There was also a message I kept seeing when I stopped the bes:  “BES seems to be running from a different location: pids 2824”  and I wasn’t sure what it meant.

Becoming close friends with OPeNDAP

•October 22, 2010 • Leave a Comment

I’ve started looking through the source code for the besdaemon and I’m learning quite a bit, not only about how the bes is running, but also about some interesting c++ functions I’ve never encountered before.  This is the first daemon program I have really looked at, so its been really fun learning about the process involved in creating a daemon. I love learning things like this, its very rewarding to look through code and look up the functions and figure out and understand what is going on in a program.  It’s always interesting to see different styles of coding, but I have to say the indentation style is quite different from anything I’ve seen before and its tripped me up a couple of times.

I finished looking through the besdaemon this morning and will try to take a look at the listener this afternoon.  Once I do this I should have a good idea of how I want to implement the changes that need to be made.

I spent a little more time looking at the besdaemon this afternoon, and I got a little confused about how it is getting the path name for it to exec the beslistener.  I ended up installing another copy of the bes for me to play around with.


•October 19, 2010 • Leave a Comment

So I created a Blog…cool.  Here is the stuff currently on my forum at twc:


  • Get rid of BES Daemon
  • have BESListener accept up to 10 connections before it refuses connections.
    • Add a line to bes.conf: BES.maxConnect=10
  • have a “go away” signal (soft kill) and a hard kill
  • keep track of children listener pids and sockets. Remove those pids/sockets when the child dies.


10-15-10: It’s been a bit of a hectic week. I have been running out of space on my ubuntu partition and am having difficulty resizing it. I currently don’t have space for the entire repo on my laptop

10-19-10: Finally got the bes repo on my laptop and started looking through the code.

Wiki Migration

  • Move ESG-CET to drupal
    • Done? nothing there to move?
  • Move OpenDAP
    • Can’t edit Releases or Documents page on old wiki
    • Related Research Page is causing issues on old wiki



  • Don’t have administer menu, so I can’t add links to the sidebar navigation.

Edit:  These wiki migration issues have been closed.