Mongrel .pids disappearing?

Server Mongrel
1

Hello everyone, new to the list :slight_smile:

Strange problem with Mongrels that we’re having in a few cases…the
Mongrels start up fine, but as part of a long Capistrano deploy +
database
we will normally cycle them - normally no issues there. In those edge
cases, we’ve seen that the mongrel .pids have just up and disappeared
while
running, so when shutting them down we get the error message that the
.pids
do not exist. Normally not a problem, except that when restarting them
(and
thereby needing to create a new pid), the log comes back with the error
message:

** Daemonized, any open files are closed. Look at log/mongrel.4102.pid
and log/mongrel.4102.log for info.
** Starting Mongrel listening at 127.0.0.1:4102
http://127.0.0.1:9002/
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/tcphack.rb:12:in
`initialize_without_backlog’: Address already in use - bind(2)
(Errno::EADDRINUSE)

Logging into the server over ssh and executing ‘sudo /usr/sbin/lsof
-i:4102’
reveals that indeed a mongrel process is running without a .pid. From
what
I can see there is no log rotation, cron job, or similar activity on the
box
that would be deleting the pids. In fact, some of the 6 .pids are there
while others are not. The pattern also changes with regard to which
ones
are missing, which is mildly aggravating.

Box is CentOS 5.1 if that helps. I also noted that someone was having
this
issue before and was cured by running the MySQL gem after seeing MySQL
connections going stale / dying on their server, but we’re already
running
the MySQL gem and are not seeing those errors in the Mongrel log.

In fact, looking at the last successful start just before the error
shown
above, there are no other errors. In other words, Mongrel starts up
daemonized without an issue or any errors in the log, and then some time
later (in this case, 2 weeks), trying to stop them generates a
nonexistent
.pid error. The subsequent start attempt generates the ‘Address already
in
use’ message, which forces us to log in and actually kill the processes
before we can start up again.

Processes without .pids don’t seem to be using more or less memory than
usual.

We are stopping and starting the mongrels with the following bash
script:

mongrel_rails cluster::start -C $MONGREL_CONF
mongrel_rails cluster::stop -C $MONGREL_CONF

Mongrel version is 1.0.1 (as described above), and MySQL gem is 2.7.

Has anyone seen a similar issue, and if so did you figure out the root
cause? I’m a bit at a loss with the mongrel logs not giving any
information
nor the system giving any inidication that it deleted the .pid files.
Any
help is greatly appreciated.

-Chris.

2

I’ve been experiencing this exact same problem for months. Still
haven’t figured out what the cause is.

I’m on solaris 10 x86

-Steven

3

Hi, did you ever find what was causing this? I have the same issue on
CentOs.

4

I spent so much time on this pid sh… googling for hours. Hope I can
help others! Seems like running as a daemon solves the problem. just add
-d at the end and it decides to create the pid file. I’m sorry if this
isn’t the problem/solution you guys are having.

mongrel_rails start -d

It really tricked me with its output on mongrel_rails.

** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no
restart).
** Rails signals registered. HUP => reload (without restart). It might
not work well.
** Mongrel 1.1.5 available at 0.0.0.0:3000

Of, course, neither restart nor stop worked, so I tried sending that
USR2 signal manually, finding it’s pid with ps, then

kill -USR2 20316

Back in the first term window I saw this:

  • USR2 signal received.
    ** Restarting with arguments: ruby
    /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails start
    Can’t restart unless in daemon mode.

OK, trying the obvious worked. You can see the pid file is there in the
log directory. Or am I totally off here??

5

I reinstalled RoR and mongrel on my Sun Solaris box and the problem
disappeared.

Kevin

6

Is there a version of mongrel out yet that has a --prefix that works
with latest versions of Rails?

When I do a “gem install mongrel”, I get mongrel 1.1.5.

Using Rails 2.3.4, if I try launching mongrel with “–prefix
/something”, I get an error about:

uninitialized constant ActionController::AbstractRequest

As this problem was first reported a year ago, I’m hoping there’s a
version of mongrel that handles it, that I just haven’t managed to
actually install with a naive “gem install mongrel”, it’s hiding
somewhere else?

Or is this really not fixed in a mongrel release yet?

Any advice welcome. (I know how to set the prefix in environment.rb
instead of mongrel command line; but I really want to do it in the
mongrel command line sometimes).

Jonathan