El Miércoles, 23 de Diciembre de 2009, Eric Wong escribió: > > > Adding this code doesn't solve problems. Either way the site can > > > become inaccessible/unusable and problems are noticeable very quickly. > > > > Sure, but how to explain that to Hearteat? :) > > I had a lot of trouble coming to terms with this one myself :) > > Eventually I reasoned that the heartbeat mechanism is to protect against > unforeseen failures way down the line (and sometimes outside of the > application's control). > > It's (hopefully) common and expected to check applications shortly > following deployments, so heartbeat isn't for that.
Yes, you are right. > However applications have a tendency to break in unforseen ways, and > only in production, and at the worst times. These failures happen well > after the app is deployed :) Yes, every application breaks just in the moment that it shouldn't :) However I'm building my app now and when start it it usually has errors, and that's good as it means I'm working :) But sincerelly I would like to see the error just once rather than many times due to workers respawn :) Also, is there any "interval" parameter so a worker is not re-spawned until such timeout (after die). > > This is: usually to verify the process status the PID file/value is > > inspected. If there is a process running under such PID then we "assume" > > that process is Unicorn. In case that PID is stolen by any other process > > (since PID file wasn't deleted) nobody realizes of it. > > Under modern Linux systems, you have several options... > > tr '\0' ' ' < /proc/$PID/cmdline # show the command-line > > pmap $PID | grep unicorn_http.so # not many other things load this > > lsof -p $PID # can check listening ports/log files Yes! this is much better! :) > Unfortunately I don't use other OSes enough to remember the > equivalents... The server will run just on Linux (Unix) server :) > > A way to determine it could be asking to Unicorn master process (using > > i.e. DRB) its PID and match it against the PID value stored in the > > pidfile. Of course it would require some kind of communication with > > unicorn master process to get its PID, is it possible now in some way? > > I don't see how being under a specific PID actually matters. Why not > just write a script that sends an HTTP request to check? > > Workers will die soon after the first request, or (timeout/2) seconds if > a master dies anyways. Well, in fact I want to code some console utility to get information from the application (loaded configuration, check the database(s) connection and so). For that I was thinking in a DRb server running in the master because it must bind in some TCP port. The problem is that I should stop the DRb server before master reexec to avoid EADDINUSE. Well, I could code some rescue block... > > I didn't know about such options in .ru file. Are those options > > supposed to be read by the backend? > > I don't believe it's well-documented, I only found out from reading the > rackup code and I'm not really a fan of magic comments, but they're only > for the basic command-line arguments rackup handles: > > $ rackup -h ... > -D, --daemonize run daemonized in the background Why "daemonize" is not present in unicornf configuration file? Really thanks a lot for all your help. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
