[Mongrel] Unix Domain Sockets + Fork for improved scalability

Brian Weaver cmdrclueless at gmail.com
Tue May 6 10:44:12 EDT 2008


See the comments embedded.....

On Tue, May 6, 2008 at 1:59 AM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Mon, May 05, 2008 at 11:37:56PM -0400, Brian Weaver wrote:
>  > Hello All,
>  >
>  > Ticket #30 (http://mongrel.rubyforge.org/ticket/30)  has a set of
>  > changes to mongrel that I've written on behalf of
>  > my employer, Raritan Computer, Inc. Also, these changes are released
>  > under the existing Ruby license used for Mongrel.
>
>  Interesting Brian, glad you finally got the patch into the queue. :-)
>
>
>  > The attached patch does just that. It's definitely tailored for a Unix
>  > derivative platform and depends on the functionality of the UNIXSocket
>  > class to pass file descriptors between instances. It works in a
>  > master-slave type of server setup. The "master" is the initial
>  > instance of mongrel rails which goes through its normal initialization
>  > gyrations before forking mulitple "slave" instances to do the actual
>  > rails processing. The server listens on the defined TCP/IP address and
>  > port accepting request (from Apache in our case), determines which
>  > child if any is available, and then hands off the file descriptor for
>  > processing.
>
>  So, I've just read through this patch, and correct me if I'm wrong, but
>  your patch removes the ability for Mongrel to run as a plain web server
>  right?  There also seems to be no tests, so does it just use the
>  existing tests but within the confines of the new forking setup?

No, the patch should not remove the ability for mongel to run a a
plain web server. I basically split the HttpServer class into two
classes: Server and HttpServer. I attempted to move most of what would
be common code between the existing HttpServer class and the new
UnixDispatchServer class into the base Server class. If you specify
'--unixmaster' or put 'unixmaster = true' in the mongrel yaml
configuration file then it runs an instance of the UnixDispatchServer;
otherwise it should run the default HttpServer as it was originally
written to do,

Your right there are currently no test. Yes you can flame me all you
want for that; I'll get to it when I have time. I figured in the
spirit of most open source projects I would go ahead and "release
early" to let people play with it so that I could get feedback. The
primary development platform was Linux (CentOS 4 actually) and I
tested it heavily with our application before I posted it. It's far
from perfect, but it is a start.

Besides other people might feel like contributing, I wouldn't want to
deprive them of a decent opportunity by writing all the test myself.
That would seem kind of greedy. ;-)

>
>
>  > The patch isn't without any warts. Due to the way that mongrel
>  > preforms initialization I found it difficult to follow the startup
>  > logic. Because of the convoluted
>  > contortions that occur during startup I was unable to
>  > make deeper changes due to time constraints which means that the
>  > following problem exists.
>
>  Can you describe what was confusing?  The code's not too large so maybe
>  it just wasn't documented really clearly.
>
>  Also, had you tried just subclassing HttpServer and implementing the
>  alternative mechanism for both the master and slaves?
>
>
>  > * If you start the server as root and the configuration causes a
>  > setuid/setgid call to a non-root user then during shutdown mongrel may
>  > not be able to remove its pid file.
>
>  The pid file management has always been a mess because of ruby's very
>  poor process management, and just the variablility in POSIX anyway.
>  Eventually it'll just have to be a C api that does it right I think.
>

Almost all systems support the 'unlink' command. At issues is when you
drop privilege levels from root after creating a pid file then it's
almost impossible to remove. I've gotten around this issue by using a
service script (/etc/init.d/mongrel_rails) on our system to check for
the existence of a pid file, ensure that the process really isn't
running, and then removing the pid before starting up mongrel. It's
not an insurmountable problem, I just figured I would state it up
front to save other developers and users some time.

One could always change the code to save the privilege level allowing
for a new call to setuid/setgid, but this could come back to bite if
the process has a vulnerability. It's a small problem to do the checks
before starting or after stopping mongrel for the added security of
running as a non-privileged user.

>
>  > I'm not aware of any other lurking problem, but I wouldn't be
>  > surprised if one or more exists.
>  >
>  > If you have any further question just send me a note or post to the
>  > list. I'll stay subscribed for a few weeks at least. Also, for the
>  > maintainers: I've added a copyright notice for Raritan Computer on
>  > those files that had extensive changes. I believe that is the correct
>  > way to handle major changes, let me know if I'm incorrect in my
>  > understanding.
>
>  Actually, and this is a big misnomer among open source folks, the
>  copyright isn't on a file, it's on the project.  It's kind of like
>  saying if you edit a page in my book with a marker you get to put your
>  copyright on that page.  Additionally there isn't enough change to that
>  file to warrant an entire copyright change as it's still primarily
>  written by myself and other project contributors.

I'm not a copyright lawyer, but I bet if you talk to a few you would
get some variance on how it really should be done. The point is the
work I've done has been for Raritan. If the changes are such that
copyright law would assign the ownership, for all or part of the
changes, to Raritan then that's who owns it. Raritan is simply trying
to follow the Ruby license that Mongrel is using....

Specifically section 2a of the license at
http://www.ruby-lang.org/en/LICENSE.txt

>
>  What you can do is either officially donate it back to the project under
>  the original copyright with a small notice giving credit to yourself
>  and/or Raritan that you did the master/slave/unixsocket hack, or pull
>  this out into a separate, completely and wholely written by you/raritan
>  file that has none of my code and then release under your own license
>  however you like.
>
>  Talk it over with your corporate masters, but considering you have an
>  entire product based on other people's generously donated free work it
>  might be a really great nice thing to give back.
>
>  Makes people all warm and fuzzy and like your products in exchange.

I know all about warm and fuzzy, giving to the community, paying for
the privilege, and being out of work with no income at the end of the
day. Luckily the work lives own and my previous company was able to
find someone to keep the open source fork going while we tried our
commercial endeavor. The commercial endeavor was a bust, but that's
life. If you have any interest in network management then you should
hop on over to OpenNMS (http://www.opennms.org/) and you can see my
first dabbling with open source.

-- Weave

-- 

/* insert witty comment here */


More information about the Mongrel-users mailing list