From code at jeremyevans.net Fri Jul 2 16:50:04 2010 From: code at jeremyevans.net (Jeremy Evans) Date: Fri, 2 Jul 2010 13:50:04 -0700 Subject: [PATCH] Show the current working directory in the proc title Message-ID: <20100702205004.GI4248@jeremyevans.local> >From 7aec3c7f83430900e91f7df854577f1bac5e7c3a Mon Sep 17 00:00:00 2001 From: Jeremy Evans Date: Fri, 2 Jul 2010 13:46:15 -0700 Subject: [PATCH] Show the current working directory in the proc title This is helpful if you run a server with many web apps in separate directories all running unicorn, as it allows you to easily see which processes are tied to which app. --- lib/unicorn.rb | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/unicorn.rb b/lib/unicorn.rb index a7b0646..a764cd7 100644 --- a/lib/unicorn.rb +++ b/lib/unicorn.rb @@ -811,8 +811,8 @@ module Unicorn end def proc_name(tag) - $0 = ([ File.basename(START_CTX[0]), tag - ]).concat(START_CTX[:argv]).join(' ') + $0 = ([ File.basename(START_CTX[0]), File.basename(START_CTX[:cwd]), + tag ]).concat(START_CTX[:argv]).join(' ') end def redirect_io(io, path) -- 1.7.0.5 From normalperson at yhbt.net Fri Jul 2 18:29:34 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 2 Jul 2010 22:29:34 +0000 Subject: [PATCH] Show the current working directory in the proc title In-Reply-To: <20100702205004.GI4248@jeremyevans.local> References: <20100702205004.GI4248@jeremyevans.local> Message-ID: <20100702222934.GA22624@dcvr.yhbt.net> Jeremy Evans wrote: > This is helpful if you run a server with many web apps in separate > directories all running unicorn, as it allows you to easily see > which processes are tied to which app. Hi Jeremy, I recommend using absolute paths with -c/--config-file and allowing users to opt-in to it (everybody should be using a Unicorn config file in production). Having an extra working directory path in there hurts people on smaller terminals[1]. With -c, users have more control of what their command-line looks like without having something forced on them. I can't see myself accepting this patch right now for the above reasons. On the other hand, I don't see any reason to alter the way proc_name is used in the future, so monkey patching here is fine. I'm sure there'll always be folks that will want something different in $0 (as evidenced by Rack::Contrib::ProcTitle and like). [1] - I try to be considerate of on-call folks working from mobile phones or netbooks and/or bad net connections. There's even a test in test_exec.rb to ensure the help output text can fit in standard 80x24 ANSI terminals. Personally, I refuse to use a terminals wider than 80 columns (actually, I would've preferred the world standardized on a 64-column wrap) -- Eric Wong From jeremyevans0 at gmail.com Fri Jul 2 18:50:26 2010 From: jeremyevans0 at gmail.com (Jeremy Evans) Date: Fri, 2 Jul 2010 15:50:26 -0700 Subject: [PATCH] Show the current working directory in the proc title In-Reply-To: <20100702222934.GA22624@dcvr.yhbt.net> References: <20100702205004.GI4248@jeremyevans.local> <20100702222934.GA22624@dcvr.yhbt.net> Message-ID: On Fri, Jul 2, 2010 at 3:29 PM, Eric Wong wrote: > Jeremy Evans wrote: >> This is helpful if you run a server with many web apps in separate >> directories all running unicorn, as it allows you to easily see >> which processes are tied to which app. > > Hi Jeremy, > > I recommend using absolute paths with -c/--config-file and allowing > users to opt-in to it (everybody should be using a Unicorn config > file in production). > > Having an extra working directory path in there hurts people on smaller > terminals[1]. ?With -c, users have more control of what their > command-line looks like without having something forced on them. > > I can't see myself accepting this patch right now for the above reasons. > On the other hand, I don't see any reason to alter the way proc_name is > used in the future, so monkey patching here is fine. > > I'm sure there'll always be folks that will want something different in > $0 (as evidenced by Rack::Contrib::ProcTitle and like). > > > [1] - I try to be considerate of on-call folks working from mobile > ? ? ?phones or netbooks and/or bad net connections. ?There's even > ? ? ?a test in test_exec.rb to ensure the help output text can fit > ? ? ?in standard 80x24 ANSI terminals. ?Personally, I refuse to use > ? ? ?a terminals wider than 80 columns (actually, I would've > ? ? ?preferred the world standardized on a 64-column wrap) Fair enough, I realize the patch wasn't for everyone. I usually change to the directory first and call unicorn with a relative path, but that's probably just a bad habit. It's fairly easy to monkey patch it in the configuration file if you need it: class Unicorn::HttpServer def proc_name(tag) $0 = ([ File.basename(START_CTX[0]), File.basename(START_CTX[:cwd]), tag ]).concat(START_CTX[:argv]).join(' ') end end I see in the NEWS entry for 0.95.1 that you do recommend an absolute path for the -c/--config-file option, but it may be beneficial to mention this in the man page or other parts of the documentation. Thanks, Jeremy From normalperson at yhbt.net Mon Jul 5 19:34:39 2010 From: normalperson at yhbt.net (Eric Wong) Date: Mon, 5 Jul 2010 23:34:39 +0000 Subject: [PATCH] Show the current working directory in the proc title In-Reply-To: References: <20100702205004.GI4248@jeremyevans.local> <20100702222934.GA22624@dcvr.yhbt.net> Message-ID: <20100705233439.GA28789@dcvr.yhbt.net> Jeremy Evans wrote: > I see in the NEWS entry for 0.95.1 that you do recommend an absolute > path for the -c/--config-file option, but it may be beneficial to > mention this in the man page or other parts of the documentation. Agreed, thanks Jeremy! >From d7695c25c5e3b1c90e63bf15a5c5fdf68bfd0c34 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Mon, 5 Jul 2010 23:14:40 +0000 Subject: [PATCH] doc: recommend absolute paths for -c/--config-file Suggested-by: Jeremy Evans ref: http://mid.gmane.org/AANLkTintT4vHGEdueuG45_RwJqFCToHi5pm2-WKDSUMz at mail.gmail.com --- Documentation/unicorn.1.txt | 3 +++ Documentation/unicorn_rails.1.txt | 7 +++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/unicorn.1.txt b/Documentation/unicorn.1.txt index 24df7ab..c20a570 100644 --- a/Documentation/unicorn.1.txt +++ b/Documentation/unicorn.1.txt @@ -36,6 +36,9 @@ with rackup(1) but strongly discouraged. implemented as a Ruby DSL, so Ruby code may executed. See the RDoc/ri for the *Unicorn::Configurator* class for the full list of directives available from the DSL. + Using an absolute path for for CONFIG_FILE is recommended as it + makes multiple instances of Unicorn easily distinguishable when + viewing ps(1) output. -D, \--daemonize : Run daemonized in the background. The process is detached from diff --git a/Documentation/unicorn_rails.1.txt b/Documentation/unicorn_rails.1.txt index 267e425..f426b07 100644 --- a/Documentation/unicorn_rails.1.txt +++ b/Documentation/unicorn_rails.1.txt @@ -34,8 +34,11 @@ as much as possible. -c, \--config-file CONFIG_FILE : Path to the Unicorn-specific config file. The config file is implemented as a Ruby DSL, so Ruby code may executed. - See the RDoc/ri for the *Unicorn::Configurator* class for the - full list of directives available from the DSL. + See the RDoc/ri for the *Unicorn::Configurator* class for the full + list of directives available from the DSL. + Using an absolute path for for CONFIG_FILE is recommended as it + makes multiple instances of Unicorn easily distinguishable when + viewing ps(1) output. -D, \--daemonize : Run daemonized in the background. The process is detached from -- Eric Wong From lawrence.pit at gmail.com Mon Jul 5 22:18:21 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Tue, 06 Jul 2010 12:18:21 +1000 Subject: [PATCH] Show the current working directory in the proc title In-Reply-To: <20100705233439.GA28789@dcvr.yhbt.net> References: <20100702205004.GI4248@jeremyevans.local> <20100702222934.GA22624@dcvr.yhbt.net> <20100705233439.GA28789@dcvr.yhbt.net> Message-ID: <4C32926D.5080400@gmail.com> The +after_fork+ doc mentions "generally there's no reason to start Unicorn as a priviledged user". "generally" that may be true, I'd still recommend to run each app as a dedicated user. The added bonus is that it makes it most obvious in ps(1) listings which app a unicorn process belongs to as 'user' is usually mentioned first. On small terminals the value of --config-file could easily be cut off at the right, still leaving you in the dark. Lawrence > Jeremy Evans wrote: > >> I see in the NEWS entry for 0.95.1 that you do recommend an absolute >> path for the -c/--config-file option, but it may be beneficial to >> mention this in the man page or other parts of the documentation. >> > > Agreed, thanks Jeremy! > > >From d7695c25c5e3b1c90e63bf15a5c5fdf68bfd0c34 Mon Sep 17 00:00:00 2001 > From: Eric Wong > Date: Mon, 5 Jul 2010 23:14:40 +0000 > Subject: [PATCH] doc: recommend absolute paths for -c/--config-file > > Suggested-by: Jeremy Evans > ref: http://mid.gmane.org/AANLkTintT4vHGEdueuG45_RwJqFCToHi5pm2-WKDSUMz at mail.gmail.com > --- > Documentation/unicorn.1.txt | 3 +++ > Documentation/unicorn_rails.1.txt | 7 +++++-- > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Documentation/unicorn.1.txt b/Documentation/unicorn.1.txt > index 24df7ab..c20a570 100644 > --- a/Documentation/unicorn.1.txt > +++ b/Documentation/unicorn.1.txt > @@ -36,6 +36,9 @@ with rackup(1) but strongly discouraged. > implemented as a Ruby DSL, so Ruby code may executed. > See the RDoc/ri for the *Unicorn::Configurator* class for the full > list of directives available from the DSL. > + Using an absolute path for for CONFIG_FILE is recommended as it > + makes multiple instances of Unicorn easily distinguishable when > + viewing ps(1) output. > > -D, \--daemonize > : Run daemonized in the background. The process is detached from > diff --git a/Documentation/unicorn_rails.1.txt b/Documentation/unicorn_rails.1.txt > index 267e425..f426b07 100644 > --- a/Documentation/unicorn_rails.1.txt > +++ b/Documentation/unicorn_rails.1.txt > @@ -34,8 +34,11 @@ as much as possible. > -c, \--config-file CONFIG_FILE > : Path to the Unicorn-specific config file. The config file is > implemented as a Ruby DSL, so Ruby code may executed. > - See the RDoc/ri for the *Unicorn::Configurator* class for the > - full list of directives available from the DSL. > + See the RDoc/ri for the *Unicorn::Configurator* class for the full > + list of directives available from the DSL. > + Using an absolute path for for CONFIG_FILE is recommended as it > + makes multiple instances of Unicorn easily distinguishable when > + viewing ps(1) output. > > -D, \--daemonize > : Run daemonized in the background. The process is detached from > From chemosh9 at gmail.com Tue Jul 6 04:20:21 2010 From: chemosh9 at gmail.com (Mark Davidson) Date: Tue, 6 Jul 2010 10:20:21 +0200 Subject: [Rails 3] Unicorn log output Message-ID: I'm just getting started with Rails 3 but noticed that unicorn doesn't tail the development log which makes sense since its not specifically for rails. I got the development log back using Rails::Rack::LogTailer and got rid of the Rack request log by setting `stderr_path` to /dev/null in the unicorn config file. That basically gives me the same behavior as unicorn_rails on 2.3.8. Is there a better or preferred way of doing this? Can Rack's default request log be disabled? I wonder why it goes to stderr anyway, cause the request log isn't exactly an error? Cheers. From normalperson at yhbt.net Tue Jul 6 05:06:43 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 6 Jul 2010 09:06:43 +0000 Subject: [Rails 3] Unicorn log output In-Reply-To: References: Message-ID: <20100706090642.GD4932@dcvr.yhbt.net> Mark Davidson wrote: > I'm just getting started with Rails 3 but noticed that unicorn doesn't > tail the development log which makes sense since its not specifically > for rails. I got the development log back using Rails::Rack::LogTailer > and got rid of the Rack request log by setting `stderr_path` to > /dev/null in the unicorn config file. That basically gives me the same > behavior as unicorn_rails on 2.3.8. > > Is there a better or preferred way of doing this? Can Rack's default > request log be disabled? I wonder why it goes to stderr anyway, cause > the request log isn't exactly an error? Hi Mark, You can pass "-E none" or set "RACK_ENV=none" in the environment to disable the default middleware 'unicorn' gives you. 'unicorn' tries to follow the 'rackup' command as closely as possible to ease transitions, so it will send Rack::CommonLogger output to $stderr when RACK_ENV is 'none' or 'deployment' just like 'rackup' does. On the subject of request logging, I prefer to use Clogger (http://clogger.rubyforge.org/) for the few deployments I do instead of Rack::CommonLogger since Clogger is configurable and (under MRI) faster (I also wrote it, so if it breaks I get to fix it :>). -- Eric Wong From mrjainkumarrr at yahoo.com.hk Mon Jul 5 19:16:43 2010 From: mrjainkumarrr at yahoo.com.hk (Mr. Jain Kumar) Date: Tue, 6 Jul 2010 01:16:43 +0200 (CEST) Subject: Please let me know if you got my last email notification to you Message-ID: <20100706000204.532C5E5C2F3@ast4u.senshi.jp> Dear Beloved, As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. My name is Jain Kumar,I am a merchant of Oman nationality but presently residing in london.I have been diagnosed with Esophageal cancer. It has defiled all forms of medical treatment, and right now I have only about a few months to live, according to medical experts. I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends. I want God to be merciful to me and accept my soul so, I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations in the Oman, Algeria and Malaysia. Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which no one knows of is the huge cash deposit of eighteen million dollars $18,000,000 that I have with a finance/Security Company in europe. I will want you to help me collect this deposit and dispatche it to charity organizations I have set aside 20% for you and for your time. God be with you. Thanks Jain Kumar From normalperson at yhbt.net Thu Jul 8 04:04:57 2010 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 8 Jul 2010 08:04:57 +0000 Subject: [ANN] unicorn 1.1.0 - small changes and cleanups Message-ID: <20100708080457.GA2345@dcvr.yhbt.net> Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at rubyforge.org * git://git.bogomips.org/unicorn.git Changes: This is a small, incremental feature release with some internal changes to better support upcoming versions of the Rainbows! and Zbatery web servers. There is no need to upgrade if you're happy with 1.0.0, but also little danger in upgrading. There is one pedantic bugfix which shouldn't affect anyone and small documentation updates as well. -- Eric Wong From congratulationfee at hotmail.com Wed Jul 7 22:28:09 2010 From: congratulationfee at hotmail.com (EURO MILLIONES LOTTERY BOARD) Date: Thu, 8 Jul 2010 04:28:09 +0200 Subject: EURO MILLIONES LOTTERY BOARD Message-ID: <20100708022811.85CEF36CAFED@lpk3.gravitynet.org> Dear internet user, http://www.euro-millions.com/ We wish to congratulate that this email mongrel-unicorn at rubyforge.org] emerged success in our computer Balloting This email address drew and have won the sum of 750,000 Euros ( Seven Hundred and Fifty Thousand Euros) in cash cr edited to file with REFERENCE NUMBER: ESP/WIN/009/0 7/10/MA; WINNING NUMBER : 14-17-24-34-37-45-16 BATCH NUMBERS : EULO/1007/444/606/09; SERIAL NUMBER: 45327 and PROMOTION DATE: 8th July. 2010 To claim your winning prize, you are to cont act the appointed agent below as soon as possible for the immediate release of your winnings with the below details. ADASE AGENCY S.L MR. David Carlos TEL: +34 672-969-328 Fax 0034-911-820-312 Email: adaseagency at luckymail.com Congratulations once again from all our staff. Mrs Maribel Smith. (Secretary) Euro Milliones Lottery Board. ********This notice has been strictly verified by the Head Anti-Scam Lottery Commission (anti-fraud unit spain), normalized only for the intented recipient.******* From paul.dlug at gmail.com Thu Jul 8 16:55:35 2010 From: paul.dlug at gmail.com (Paul Dlug) Date: Thu, 8 Jul 2010 16:55:35 -0400 Subject: Setting app name for process list Message-ID: Is there a way to set an application name for unicorn processes? Basically an arbitrary name which would then show up in the process list to identify unicorn processes, like what thin does with --tag. I'm running unicorn for several apps on the same host and finding it hard to track which is which, also useful for various monitoring scripts to ensure that X number of processes are running. --Paul From dbenhur at whitepages.com Thu Jul 8 17:22:23 2010 From: dbenhur at whitepages.com (Devin Ben-Hur) Date: Thu, 8 Jul 2010 14:22:23 -0700 Subject: Setting app name for process list In-Reply-To: References: Message-ID: <4C36418F.4010209@whitepages.com> On 7/8/10 1:55 PM, Paul Dlug wrote: > Is there a way to set an application name for unicorn processes? > Basically an arbitrary name which would then show up in the process > list to identify unicorn processes, like what thin does with --tag. A patch to do something like that was recently rejected. Instead the documentation was updated with Eric's recommendated solution to instance identification: http://rubyforge.org/pipermail/mongrel-unicorn/2010-July/000620.html + Using an absolute path for for CONFIG_FILE is recommended as it + makes multiple instances of Unicorn easily distinguishable when + viewing ps(1) output. From normalperson at yhbt.net Thu Jul 8 17:42:09 2010 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 8 Jul 2010 14:42:09 -0700 Subject: Setting app name for process list In-Reply-To: <4C36418F.4010209@whitepages.com> References: <4C36418F.4010209@whitepages.com> Message-ID: <20100708214209.GA7500@dcvr.yhbt.net> Devin Ben-Hur wrote: > On 7/8/10 1:55 PM, Paul Dlug wrote: >> Is there a way to set an application name for unicorn processes? >> Basically an arbitrary name which would then show up in the process >> list to identify unicorn processes, like what thin does with --tag. > > A patch to do something like that was recently rejected. Instead the > documentation was updated with Eric's recommendated solution to instance > identification: > http://rubyforge.org/pipermail/mongrel-unicorn/2010-July/000620.html > > + Using an absolute path for for CONFIG_FILE is recommended as it > + makes multiple instances of Unicorn easily distinguishable when > + viewing ps(1) output. Lawrence Pit also recommends running each app as a separate user, which is also a great idea (IMHO, though some ops people I know dislike this): http://mid.gmane.org/4C32926D.5080400 at gmail.com -- Eric Wong From paul.dlug at gmail.com Fri Jul 9 01:09:01 2010 From: paul.dlug at gmail.com (Paul Dlug) Date: Fri, 9 Jul 2010 01:09:01 -0400 Subject: Setting app name for process list In-Reply-To: <20100708214209.GA7500@dcvr.yhbt.net> References: <4C36418F.4010209@whitepages.com> <20100708214209.GA7500@dcvr.yhbt.net> Message-ID: On Thu, Jul 8, 2010 at 5:42 PM, Eric Wong wrote: > Devin Ben-Hur wrote: >> On 7/8/10 1:55 PM, Paul Dlug wrote: >>> Is there a way to set an application name for unicorn processes? >>> Basically an arbitrary name which would then show up in the process >>> list to identify unicorn processes, like what thin does with --tag. >> >> A patch to do something like that was recently rejected. Instead the >> documentation was updated with Eric's recommendated solution to instance >> identification: >> http://rubyforge.org/pipermail/mongrel-unicorn/2010-July/000620.html >> >> + ? ?Using an absolute path for for CONFIG_FILE is recommended as it >> + ? ?makes multiple instances of Unicorn easily distinguishable when >> + ? ?viewing ps(1) output. > > Lawrence Pit also recommends running each app as a separate user, > which is also a great idea (IMHO, though some ops people I know > dislike this): > > ? http://mid.gmane.org/4C32926D.5080400 at gmail.com I think both of these solutions are undesirable, relying on the config file path is not ideal and running with different users is practical in my environment. Both these point out the need for some feature to distinguish running applications, I think adding a configurable application name/tag would be very useful, not sure how much work it would be but I can look at adding a patch if there is interest. --Paul From jeremyevans0 at gmail.com Fri Jul 9 01:44:14 2010 From: jeremyevans0 at gmail.com (Jeremy Evans) Date: Thu, 8 Jul 2010 22:44:14 -0700 Subject: Setting app name for process list In-Reply-To: References: <4C36418F.4010209@whitepages.com> <20100708214209.GA7500@dcvr.yhbt.net> Message-ID: On Thu, Jul 8, 2010 at 10:09 PM, Paul Dlug wrote: > On Thu, Jul 8, 2010 at 5:42 PM, Eric Wong wrote: >> Devin Ben-Hur wrote: >>> On 7/8/10 1:55 PM, Paul Dlug wrote: >>>> Is there a way to set an application name for unicorn processes? >>>> Basically an arbitrary name which would then show up in the process >>>> list to identify unicorn processes, like what thin does with --tag. >>> >>> A patch to do something like that was recently rejected. Instead the >>> documentation was updated with Eric's recommendated solution to instance >>> identification: >>> http://rubyforge.org/pipermail/mongrel-unicorn/2010-July/000620.html >>> >>> + ? ?Using an absolute path for for CONFIG_FILE is recommended as it >>> + ? ?makes multiple instances of Unicorn easily distinguishable when >>> + ? ?viewing ps(1) output. >> >> Lawrence Pit also recommends running each app as a separate user, >> which is also a great idea (IMHO, though some ops people I know >> dislike this): >> >> ? http://mid.gmane.org/4C32926D.5080400 at gmail.com > > I think both of these solutions are undesirable, relying on the config > file path is not ideal and running with different users is practical > in my environment. Both these point out the need for some feature to > distinguish running applications, I think adding a configurable > application name/tag would be very useful, not sure how much work it > would be but I can look at adding a patch if there is interest. The patch was already submitted and rejected. If you want this feature, you can implement it yourself in the config file with the following code: class Unicorn::HttpServer def proc_name(tag) $0 = ([ File.basename(START_CTX[0]), "application name/tag", tag ]).concat(START_CTX[:argv]).join(' ') end end Jeremy From normalperson at yhbt.net Sat Jul 10 23:05:32 2010 From: normalperson at yhbt.net (Eric Wong) Date: Sun, 11 Jul 2010 03:05:32 +0000 Subject: [ANN] unicorn 1.1.1 - fixing cleanups gone bad :x In-Reply-To: <20100708080457.GA2345@dcvr.yhbt.net> References: <20100708080457.GA2345@dcvr.yhbt.net> Message-ID: <20100711030532.GA22441@dcvr.yhbt.net> Unicorn::TeeInput constant resolution for Unicorn::ClientError got broken simplifying code for RDoc. This affects users of Rainbows! and Zbatery. I've also made new minor releases for Rainbows! (0.95.1) and Zbatery (0.3.1) users to depend on Unicorn 1.1.1 -- Eric Wong From sue at mail.nexchannel.cl Mon Jul 12 11:46:30 2010 From: sue at mail.nexchannel.cl (henpeck Merritt) Date: Mon, 12 Jul 2010 15:46:30 -0000 Subject: Healthcare, Business and Finance mailing/email lists Message-ID: 31d1b0902fe024a971afd5bfbd33deb7 Until Friday Jul 16 you can buy any list below for just $150 each, 3 for $299 or 5 for $399: All lists are 100% optin and are 6 months or newer. ** HEALTHCARE LISTS ** - Physicians (34 specialties) - 788k records, 17k emails, 200k fax numbers - Chiropractors - 108,421 total records * 3,414 emails * 6,553 fax numbers - Alternative Medicine - 1,141,602 total records with 36,320 emails and 38.935 fax numbers - Dentists - 164k records, 45k emails, 77k fax numbers - Veterinarians - 78,986 total records with 1,438?emails and 1,050?fax numbers - Hospitals - 23,747 Hospital Administrators in over 7,145 Hospitals (full contact info no emails) - National Health Service Corp Clinics - 1,300 total records with emails for government run free clinics - Nursing Homes - 31,589 Senior Administrators, 11,288 Nursing Directors in over 14,706 Nursing Homes (full contact info no emails) - Pharmaceutical Companies - Email only list 47,000 emails of pharma company employees - Physical Therapists - 125,460 total records with 5,483 emails and 4,405 fax numbers - Oncology Doctors - 2,200 records all with emails - US Surgery Centers - 85k records and 14k emails - Massage Therapists - 76,701 records and 8,305 emails - Acupuncturists - 23,988 records 1,826 emails - Medical Equipment Suppliers - 167,425 total records with 6,940 emails and 5,812 fax numbers - Mental Health Counselors - 283,184 records 7,206 emails - Visiting Nurses & RN's - 91,386 total records with 2,788 emails and 2,390 fax numbers - Optometrists - 63,837 records 2,015 emails - Psychologists - 272,188 records and 9,874 emails ** BUSINESS AND FINANCE LISTS ** - Hotels - 34,815 total records * 1,642 emails - Real Estate Agents - 1 million records with emails - American Business Email List - 2 million emails various businesses - US New Business Database - 4.8 million records all with emails - Manufacturers Database - 1,057,119 records with 476,509 emails - Financial Planners Database - 148,857 records all with emails - Finance and Money Professionals Database - 116,568 records all with emails ** CONSUMER LISTS ** - American Consumer Database - 300,000 records all with emails. - Credit Inquiries Database - 1 million Full Data Records all with emails - American Homeowners - 1 million Full Data Records all with emails ** PROFESSIONALS LISTS ** - USA Lawyers Database - 269,787 records with 235,244 emails - Police and Sheriff Services - 42,987 records and 114 emails - Criminal Attorneys - 142,906 total records, 99,857 emails email me if you're interested: toplists at gmx.com to adjust your subscription status email to offthelist at gmx.com From lawrence.pit at gmail.com Tue Jul 13 00:25:51 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Tue, 13 Jul 2010 14:25:51 +1000 Subject: SIGWINCH Message-ID: <4C3BEACF.7040301@gmail.com> Hi, I followed the procedure to replace a running unicorn. Works fine, except for one thing: after I decide to back out, ie I send a HUP to the old master followed by a QUIT to the new master, then: 1. the new master does die, and the old master does work again 2. the "old" master keeps running with a process name of "master (old)" 3. the "old" master keeps running with a pid file named unicorn.pid.oldbin Because the file is now named unicorn.pid.oldbin a later attempt to deploy using scripts is made rather difficult as they assume a pid file named unicorn.pid. How could I get unicorn to rename the pid file back to unicorn.pid ? I see some code in method +reap_all_workers+ that suggests it would rename the pid file back to its original, but for some reason it doesn't for me. Am I missing a step? PS. Using unicorn 1.1.1. Cheers, Lawrence From normalperson at yhbt.net Tue Jul 13 00:34:04 2010 From: normalperson at yhbt.net (Eric Wong) Date: Mon, 12 Jul 2010 21:34:04 -0700 Subject: SIGWINCH In-Reply-To: <4C3BEACF.7040301@gmail.com> References: <4C3BEACF.7040301@gmail.com> Message-ID: <20100713043404.GC9716@dcvr.yhbt.net> Lawrence Pit wrote: > Hi, > > I followed the procedure to replace a running unicorn. Works fine, > except for one thing: after I decide to back out, ie I send a HUP to the > old master followed by a QUIT to the new master, then: > > 1. the new master does die, and the old master does work again > > 2. the "old" master keeps running with a process name of "master (old)" > > 3. the "old" master keeps running with a pid file named unicorn.pid.oldbin > > Because the file is now named unicorn.pid.oldbin a later attempt to > deploy using scripts is made rather difficult as they assume a pid file > named unicorn.pid. > > How could I get unicorn to rename the pid file back to unicorn.pid ? I > see some code in method +reap_all_workers+ that suggests it would rename > the pid file back to its original, but for some reason it doesn't for > me. Am I missing a step? Hi Lawrence, Are you using a config file to specify pid or --pid from the command-line? The config file should be more reliable. I'll take a deeper look at it in a bit. -- Eric Wong From lawrence.pit at gmail.com Tue Jul 13 00:48:48 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Tue, 13 Jul 2010 04:48:48 +0000 (UTC) Subject: SIGWINCH References: <4C3BEACF.7040301@gmail.com> <20100713043404.GC9716@dcvr.yhbt.net> Message-ID: > > How could I get unicorn to rename the pid file back to unicorn.pid ? I > > see some code in method +reap_all_workers+ that suggests it would rename > > the pid file back to its original, but for some reason it doesn't for > > me. Am I missing a step? > > Hi Lawrence, > > Are you using a config file to specify pid or --pid from the > command-line? The config file should be more reliable. I'll take a > deeper look at it in a bit. > Hi Eric, I'm using both. I have an /etc/init.d/unicorn script which is somewhat like your examples/init.sh (using start-stop-daemon instead of kill though) and a config file that is like your examples/unicorn_conf.rb (comments left untouched). Cheers, Lawrence From lawrence.pit at gmail.com Tue Jul 13 03:38:59 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Tue, 13 Jul 2010 17:38:59 +1000 Subject: SIGWINCH In-Reply-To: <20100713043404.GC9716@dcvr.yhbt.net> References: <4C3BEACF.7040301@gmail.com> <20100713043404.GC9716@dcvr.yhbt.net> Message-ID: <4C3C1813.50000@gmail.com> > Are you using a config file to specify pid or --pid from the > command-line? The config file should be more reliable. I'll take a > deeper look at it in a bit. > fwiw, this is the /etc/init.d/unicorn script I'm using so far: http://gist.github.com/473547 Perhaps it's of use to others as well. Background: the main feature I'm looking for is to deploy code using /etc/init.d/unicorn upgrade. Then a dozen (full stack) checks are executed which must all pass before the app is considered to be up. Depending on the outcome of those checks an /etc/init.d/unicorn commit or rollback follows. Cheers, Lawrence From normalperson at yhbt.net Tue Jul 13 04:24:23 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 13 Jul 2010 01:24:23 -0700 Subject: SIGWINCH In-Reply-To: <4C3BEACF.7040301@gmail.com> References: <4C3BEACF.7040301@gmail.com> Message-ID: <20100713082423.GA11478@dcvr.yhbt.net> Lawrence Pit wrote: > Hi, > > I followed the procedure to replace a running unicorn. Works fine, > except for one thing: after I decide to back out, ie I send a HUP to the > old master followed by a QUIT to the new master, then: Ah, ok. I can reproduce it. The problem is the HUP by the old master tries to reset the pid file to the non-"oldbin" version which the new master is still holding on to. You could QUIT the new master first and then HUP, but this is _far_ from ideal because it leaves you with a window without running workers (and also it contradicts our documentation). It's also difficult to avoid race conditions this way. I'm looking for a better way to go about this, pid files are nasty :x -- Eric Wong From normalperson at yhbt.net Tue Jul 13 16:19:45 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 13 Jul 2010 20:19:45 +0000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks Message-ID: <20100713201945.GB16925@dcvr.yhbt.net> Changes: Theses release fix a long-standing bug where the original PID file is not restored when rolling back from a USR2 upgrade. Presumably most upgrades aren't rolled back, so it took over a year to notice this issue. Thanks to Lawrence Pit for discovering and reporting this issue. About Unicorn: Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at rubyforge.org * git://git.bogomips.org/unicorn.git -- Eric Wong From lawrence.pit at gmail.com Tue Jul 13 20:13:52 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Wed, 14 Jul 2010 10:13:52 +1000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <20100713201945.GB16925@dcvr.yhbt.net> References: <20100713201945.GB16925@dcvr.yhbt.net> Message-ID: <4C3D0140.6080806@gmail.com> Hi Eric, Thanks mate. Unfortunately this still doesn't seem to work for me. I went through the process manually, you can see a transcript at http://pastie.org/1043347.txt The indented text is what I see appearing in the unicorn stderr.log. As you can see it reports two errors during the process, saying unicorn.pid is stale. I wonder whether this is because in my unicorn config file I mention: pid "/var/www/staging/current/tmp/pids/unicorn.pid" whereas in your back_out_of_upgrade test you don't have such a line? Cheers, Lawrence > Changes: > > Theses release fix a long-standing bug where the original PID > file is not restored when rolling back from a USR2 upgrade. > Presumably most upgrades aren't rolled back, so it took over a > year to notice this issue. Thanks to Lawrence Pit for > discovering and reporting this issue. > > About Unicorn: > > Unicorn is an HTTP server for Rack applications designed to only serve > fast clients on low-latency, high-bandwidth connections and take > advantage of features in Unix/Unix-like kernels. Slow clients should > only be served by placing a reverse proxy capable of fully buffering > both the the request and response in between Unicorn and slow clients. > > * http://unicorn.bogomips.org/ > * mongrel-unicorn at rubyforge.org > * git://git.bogomips.org/unicorn.git > > From normalperson at yhbt.net Tue Jul 13 20:38:53 2010 From: normalperson at yhbt.net (Eric Wong) Date: Wed, 14 Jul 2010 00:38:53 +0000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <4C3D0140.6080806@gmail.com> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> Message-ID: <20100714003853.GA30485@dcvr.yhbt.net> Lawrence Pit wrote: > Hi Eric, > > Thanks mate. Unfortunately this still doesn't seem to work for me. > > I went through the process manually, you can see a transcript at > http://pastie.org/1043347.txt > The indented text is what I see appearing in the unicorn stderr.log. Thanks Lawrence, the following line looks suspicious to me: reaped # exec()-ed Which makes it seem like http://git.bogomips.org/cgit/unicorn.git/commit/?id=3f0f9d6 didn't get applied (and I just checked the 1.1.2 gem and it looks good to me) Can you dump out the ENV hash in your before_exec hook of your unicorn.conf.rb? I'm wondering if GEM_HOME or GEM_PATH is set and doing anything funky, causing you to load an old version of Unicorn: before_exec do |server| ENV.each do |key,value| server.logger.info "#{key}=#{value}" end end > As you can see it reports two errors during the process, saying > unicorn.pid is stale. > > I wonder whether this is because in my unicorn config file I mention: > > pid "/var/www/staging/current/tmp/pids/unicorn.pid" > > whereas in your back_out_of_upgrade test you don't have such a line? It does, I create a similar line in the unicorn_setup() function of test-lib.sh -- Eric Wong From eurolottry at secretarias.com Tue Jul 13 20:09:51 2010 From: eurolottry at secretarias.com (Mrs. Gabriela Maria Jose) Date: Wed, 14 Jul 2010 02:09:51 +0200 Subject: Good News Message-ID: <20100714000935.D726841C49F@lpk3.gravitynet.org> SPAINISH BONO LOTO Plaza De Colon 28046, Madrid, Spain YOU?RE REF: OES/3.259839603/05 BATCH NO: 297/81597/LPD. Date: 13th July, 2010 Dear Beneficiary, RE: AWARD NOTIFICATION We are pleased to inform you of the release today the 13th July, 2010 the results of the SPAINISH LOTTERY INTERNATIONAL PROMOTIONS PROGRAMS held on the 11th may, 2010. Your email mongrel-unicorn at rubyforge.org attached to the ticket number 38569 with serial number 643 drew the lucky numbers 01-35-06-41-07-56 which consequently won this lottery via the 2nd category. You have therefore been enlisted for a payout totalling ?750,000.00 (Seven Hundred And Fifty Thousand Euro Only) credited to FILE/REF. NO: OES/3259839603/05.This is from a total cash prize of ?9,468,770:00 (NINE MILLION, FOUR HUNDRED AND SIXTY EIGHT THOUSAND, SEVEN HUNDRED AND SEVENTY EUROS ONLY) Shared among seven international winners from the category I, 2 & 3. CONGRATULATIONS! Your prize money is now marked for remittance in your name, pending final approval from the European Lottery Guild. Due to mixed up of some vital information, we ask that you keep this award from public notice until your claim has been processed and your prize money remitted to your Chosen Bank Account. This is part of our security protocol to avoid double claims and unwarranted abuse of this program by participants. Note: You will be required to obtaining and notarizing a vetting approval from the Spanish High Court of Justice, Madrid Spain before your prize money can be transferred and this process will be done by our accredited claims agent. All participants were selected through a random ballot system drawn from 250,000 names from Europe, Asia, North America and the Middle East as part of our international promotional program which we conduct every year. We hope that with part of your prize money, you will take part in next year?s ?1.3 billion international Lottery. The European Lottery Guild guarantees official confirmation of your participation after you have entered. Furthermore, to file for your claim kindly contact our claims agent, Name: Mr. Mark Pinto Liberty Seguros S.A Madrid, Spain. Email: asa_claimsagency at informaticos.com Email:libertyseguros at secretarias.com Telephone: +34 672 914 106 In order to avoid unnecessary delays and complications, endeavour to quote your reference and batch numbers in every correspondence with us or your agent. Finally, should there be any change of address do inform your claim agent as soon as possible. Congratulations once again from our management and staff. Yours in service, Mrs. Gabriela Maria Jose, (Director) From lawrence.pit at gmail.com Tue Jul 13 22:14:20 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Wed, 14 Jul 2010 12:14:20 +1000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <20100714003853.GA30485@dcvr.yhbt.net> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> <20100714003853.GA30485@dcvr.yhbt.net> Message-ID: <4C3D1D7C.6010200@gmail.com> Hi Eric, At the top of my pastie http://pastie.org/1043347.txt you can see that when I request of list of gems it mentions only unicorn v1.1.2 I also added the suggested logging to the before_fork block and I also logged the unicorn version. Interesting output. First it runs the master with Unicorn v1.1.2. But when I send a USR2 it exec'ed with a Unicorn v1.1.1 for the new master. So yes, I still had a version lying around, namely in the $APP_ROOT/vendor/bundler_gems dir. See also: http://pastie.org/1043487.txt It does do this though after a USR2: executing ["/usr/local/rvm/gems/ree-1.8.7-2010.02/bin/unicorn_rails", "-D", "-E", "staging", "-c", "/var/www/staging/current/config/unicorn/staging.rb"] I.e., it tries to exec exactly how I start unicorn. That unicorn_rails binary in that path is definitely v1.1.2. So I don't quite understand why the reexeced one is picking the version from the vendor/bundler_gems dir. I need to play a bit more with this.. I'll probably have to change my /etc/init.d/unicorn script so that it starts with the vendor/bundler_gems version instead of a system-wide version :o I'll get back to you.. Cheers, Lawrence > Lawrence Pit wrote: > >> Hi Eric, >> >> Thanks mate. Unfortunately this still doesn't seem to work for me. >> >> I went through the process manually, you can see a transcript at >> http://pastie.org/1043347.txt >> The indented text is what I see appearing in the unicorn stderr.log. >> > > Thanks Lawrence, the following line looks suspicious to me: > > reaped # exec()-ed > > Which makes it seem like > http://git.bogomips.org/cgit/unicorn.git/commit/?id=3f0f9d6 didn't get > applied (and I just checked the 1.1.2 gem and it looks good to me) > > Can you dump out the ENV hash in your before_exec hook of your > unicorn.conf.rb? I'm wondering if GEM_HOME or GEM_PATH is set > and doing anything funky, causing you to load an old version > of Unicorn: > > before_exec do |server| > ENV.each do |key,value| > server.logger.info "#{key}=#{value}" > end > end > > >> As you can see it reports two errors during the process, saying >> unicorn.pid is stale. >> >> I wonder whether this is because in my unicorn config file I mention: >> >> pid "/var/www/staging/current/tmp/pids/unicorn.pid" >> >> whereas in your back_out_of_upgrade test you don't have such a line? >> > > It does, I create a similar line in the unicorn_setup() function of > test-lib.sh > > From normalperson at yhbt.net Tue Jul 13 22:34:09 2010 From: normalperson at yhbt.net (Eric Wong) Date: Wed, 14 Jul 2010 02:34:09 +0000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <4C3D1D7C.6010200@gmail.com> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> <20100714003853.GA30485@dcvr.yhbt.net> <4C3D1D7C.6010200@gmail.com> Message-ID: <20100714023409.GB31092@dcvr.yhbt.net> Lawrence Pit wrote: > Hi Eric, > > At the top of my pastie http://pastie.org/1043347.txt you can see that > when I request of list of gems it mentions only unicorn v1.1.2 > > I also added the suggested logging to the before_fork block and I also > logged the unicorn version. Interesting output. First it runs the master > with Unicorn v1.1.2. But when I send a USR2 it exec'ed with a Unicorn > v1.1.1 for the new master. So yes, I still had a version lying around, > namely in the $APP_ROOT/vendor/bundler_gems dir. > > See also: http://pastie.org/1043487.txt > > It does do this though after a USR2: > > executing ["/usr/local/rvm/gems/ree-1.8.7-2010.02/bin/unicorn_rails", > "-D", "-E", "staging", "-c", > "/var/www/staging/current/config/unicorn/staging.rb"] > > I.e., it tries to exec exactly how I start unicorn. That unicorn_rails > binary in that path is definitely v1.1.2. So I don't quite understand > why the reexeced one is picking the version from the vendor/bundler_gems > dir. It's probably loading 1.1.1 because of GEM_HOME/GEM_PATH being set. The "unicorn_rails"/"unicorn" wrappers just activates whatever gems it sees, and GEM_HOME/GEM_PATH can influence the wrapper. Managing RubyGems installations is still tricky :< > I need to play a bit more with this.. I'll probably have to change my > /etc/init.d/unicorn script so that it starts with the > vendor/bundler_gems version instead of a system-wide version :o I'll > get back to you.. Take a look at http://unicorn.bogomips.org/Sandbox.html According to Jamie, using "bundle exec unicorn_rails" is the correct way to go. -- Eric Wong From lawrence.pit at gmail.com Wed Jul 14 03:00:15 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Wed, 14 Jul 2010 17:00:15 +1000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <20100714023409.GB31092@dcvr.yhbt.net> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> <20100714003853.GA30485@dcvr.yhbt.net> <4C3D1D7C.6010200@gmail.com> <20100714023409.GB31092@dcvr.yhbt.net> Message-ID: <4C3D607F.2080701@gmail.com> >> I need to play a bit more with this.. I'll probably have to change my >> /etc/init.d/unicorn script so that it starts with the >> vendor/bundler_gems version instead of a system-wide version :o I'll >> get back to you.. >> > > Take a look at http://unicorn.bogomips.org/Sandbox.html According to > Jamie, using "bundle exec unicorn_rails" is the correct way to go. > Thanks. Yes indeed, bundle exec is the way to go. I've got it rolling back nicely now. It appears unicorn rolls back by itself when it can't start the new master. Nice! Jamie also mentions to use the shared vendor/bundler_gems path. Though I do use that in all my projects I'm not so sure it's wise to do when you can't afford any downtime. I'll have to wait for unicorn v1.1.3 before I can test whether rolling back will indeed continue with unicorn v1.1.2 instead of v1.1.3 ;o Cheers, Lawrence From jamie at tramchase.com Thu Jul 15 14:07:15 2010 From: jamie at tramchase.com (Jamie Wilkinson) Date: Thu, 15 Jul 2010 11:07:15 -0700 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <4C3D607F.2080701@gmail.com> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> <20100714003853.GA30485@dcvr.yhbt.net> <4C3D1D7C.6010200@gmail.com> <20100714023409.GB31092@dcvr.yhbt.net> <4C3D607F.2080701@gmail.com> Message-ID: <40ECA3FF-C778-4198-B162-D2A12230D85E@tramchase.com> On Jul 14, 2010, at 12:00 AM, Lawrence Pit wrote: > It appears unicorn rolls back by itself when it can't start the new master. Nice! > > Jamie also mentions to use the shared vendor/bundler_gems path. Though I do use that in all my projects I'm not so sure it's wise to do when you can't afford any downtime. I'll have to wait for unicorn v1.1.3 before I can test whether rolling back will indeed continue with unicorn v1.1.2 instead of v1.1.3 ;o Hi Lawrence, why does the shared vendor/bundler_gems cause you downtime? From not re-bundling during rollback? FWIW I made that recommendation because I ran into issues with unicorns not restarting correctly after running `cap deploy:cleanup`, since the `bundle exec` launches a binary with a path like /app/releases/201007125236/bin/unicorn, which goes missing after N deploys. I haven't tested if this applies to more recent versions Shared bundles are also significantly faster -- `bundle check || bundle install` is ~1s for me vs. several minutes to totally rebundle -jamie http://jamiedubs.com http://fffff.at From almightylinuxgod at me.com Thu Jul 15 16:46:49 2010 From: almightylinuxgod at me.com (Richard Penwell) Date: Thu, 15 Jul 2010 16:46:49 -0400 Subject: Problem with x-www-form-urlencoded Message-ID: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> Howdy all, I'm having a strange issue after moving from Thin to Unicon. One of the form values being posted is not showing up in our request, below you can see a Rails log entry and notice that there is no parameter 'messageID' but it shows in the 'action_dispatch.request.request_parameters' collection. Has anyone else seen this, and is there a solution? Started POST "/smsGatewayClient/notifyMultimediaMessageDelivered" for 10.244.90.114 at Thu Jul 15 13:39:26 -0700 2010 Processing by MessagesController#discovered as */* Parameters: {"deliveryResponse"=>"\r\n\r\n\r\n0AB1A686B00E00002010000101\r\n\r\n\r\n\r\n6.8.0\r\n0AB1A686B00E000020100001\r\n\r\n6178331496\r\n\r\n\r\n78000\r\n\r\n2010-07-15T20:38:55+00:00\r\nRetrieved\r\n\r\n\r\n\r\n", "destination"=>"tel:6178331496", "method"=>"post", "clientTransactionID"=>"21qb7g71m72i5l21ks6t85q3t5sc\">", "serviceCode"=>"78000", "outputState"=>"C", "charset"=>"UTF-8\", \"SERVER_PROTOCOL\"=>\"HTTP/1.0\", \"action_dispatch.secret_token\"=>\"REDACTED\", \"rack.run_once\"=>false, \"rack.version\"=>[1, 1], \"SERVER_SOFTWARE\"=>\"Unicorn 1.1.2\", \"PATH_INFO\"=>\"/smsGatewayClient/notifyMultimediaMessageDelivered\", \"REMOTE_ADDR\"=>\"127.0.0.1\", \"action_dispatch.request.path_parameters\"=>{:action=>\"index\", :controller=>\"forward\", :url=>\"notifyMultimediaMessageDelivered\"}, \"SCRIPT_NAME\"=>\"\", \"action_dispatch.parameter_filter\"=>[:password], \"rack.multithread\"=>false, \"HTTP_VERSION\"=>\"HTTP/1.0\", \"action_dispatch.request.request_parameters\"=>{\"deliveryResponse\"=>\"\\r\\n\\r\\n\\r\\n0AB1A686B00E00002010000101\\r\\n\\r\\n\\r\\n\\r\\n6.8.0\\r\\n0AB1A686B00E000020100001\\r\\n\\r\\n6178331496\\r\\n\\r\\n\\r\\n78000\\r\\n\\r\\n2010-07-15T20:38:55 00:00\\r\\nRetrieved\\r\\n\\r\\n\\r\\n\\r\\n\", \"messageID\"=>\"1s2oqbn15s4j3t2jbsgft72ijqh9\", \"destination\"=>\"tel:6178331496\", \"clientTransactionID\"=>\"21qb7g71m72i5l21ks6t85q3t5sc\", \"serviceCode\"=>\"78000\", \"outputState\"=>\"C\"}, \"rack.request.form_vars\"=>\"messageID=1s2oqbn15s4j3t2jbsgft72ijqh9", "#"nil, req={\"action_dispatch.request.formats\"=>[#], \"action_dispatch.request.parameters\"=>{\"deliveryResponse\"=>\"\\r\\n\\r\\n\\r\\n0AB1A686B00E00002010000101\\r\\n\\r\\n\\r\\n\\r\\n6.8.0\\r\\n0AB1A686B00E000020100001\\r\\n\\r\\n6178331496\\r\\n\\r\\n\\r\\n78000\\r\\n\\r\\n2010-07-15T20:38:55 00:00\\r\\nRetrieved\\r\\n\\r\\n\\r\\n\\r\\n\", \"messageID\"=>\"1s2oqbn15s4j3t2jbsgft72ijqh9\", \"destination\"=>\"tel:6178331496\", \"sender\"=>\"6178331496\", \"action\"=>\"index\", \"url\"=>\"notifyMultimediaMessageDelivered\", \"clientTransactionID\"=>\"21qb7g71m72i5l21ks6t85q3t5sc\", \"serviceCode\"=>\"78000\", \"outputState\"=>\"C\", \"controller\"=>\"forward\"}, \"rack.session\"=>{\"session_id\"=>\"b059b627561cc047dd7ab3e7e8de0baf\"}, \"rack.logger\"=>#, @dev=#, @shift_size=1048576>, @formatter=#, @level=0, @default_formatter=#, @progname=nil>, \"SERVER_NAME\"=>\"cdngw.g8wave.com\", \"HTTP_HOST\"=>\"cdngw.g8wave.com\", \"action_dispatch.remote_ip\"=>#, \"rack.url_scheme\"=>\"http\", \"CONTENT_LENGTH\"=>\"1332\", \"HTTP_USER_AGENT\"=>\"Jakarta Commons-HttpClient/3.0\", \"HTTP_X_REAL_IP\"=>\"10.244.90.114\", \"REQUEST_PATH\"=>\"/smsGatewayClient/notifyMultimediaMessageDelivered\", \"action_dispatch.request.query_parameters\"=>{\"sender\"=>\"6178331496\"}, \"rack.errors\"=>#, \"CONTENT_TYPE\"=>\"application/x-www-form-urlencoded"} Eternally grateful, R From normalperson at yhbt.net Thu Jul 15 18:14:02 2010 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 15 Jul 2010 15:14:02 -0700 Subject: Problem with x-www-form-urlencoded In-Reply-To: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> References: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> Message-ID: <20100715221402.GA31045@dcvr.yhbt.net> Richard Penwell wrote: > Howdy all, > I'm having a strange issue after moving from Thin to Unicon. One of > the form values being posted is not showing up in our request, below > you can see a Rails log entry and notice that there is no parameter > 'messageID' but it shows in the > 'action_dispatch.request.request_parameters' collection. Hi Richard, Which versions of Rails and Rack are you using? There's a chance Thin and Unicorn could be loading different versions of Rack and we might be hitting a bug in one version of Rack. > Has anyone else seen this, and is there a solution? I haven't seen nor looked into this myself, but I've heard some talk of multipart oddness in the Rack mailing list -- Eric Wong From almightylinuxgod at me.com Thu Jul 15 18:30:35 2010 From: almightylinuxgod at me.com (Richard Penwell) Date: Thu, 15 Jul 2010 18:30:35 -0400 Subject: Problem with x-www-form-urlencoded In-Reply-To: <20100715221402.GA31045@dcvr.yhbt.net> References: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> <20100715221402.GA31045@dcvr.yhbt.net> Message-ID: <6A2DBCB2-916B-49DD-A513-360494AAA73E@me.com> So I discovered this was a problem whereby request.body.to_s behaves differently. I wonder if TeeStream should define to_s as an alias for read? Sent from my iPhone On Jul 15, 2010, at 6:14 PM, Eric Wong wrote: > Richard Penwell wrote: >> Howdy all, > >> I'm having a strange issue after moving from Thin to Unicon. One of >> the form values being posted is not showing up in our request, below >> you can see a Rails log entry and notice that there is no parameter >> 'messageID' but it shows in the >> 'action_dispatch.request.request_parameters' collection. > > Hi Richard, Which versions of Rails and Rack are you using? > > There's a chance Thin and Unicorn could be loading different > versions of Rack and we might be hitting a bug in one version > of Rack. > >> Has anyone else seen this, and is there a solution? > > I haven't seen nor looked into this myself, but I've heard some talk of > multipart oddness in the Rack mailing list > > -- > Eric Wong From lawrence.pit at gmail.com Thu Jul 15 18:33:03 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Fri, 16 Jul 2010 08:33:03 +1000 Subject: TTIN after WINCH Message-ID: <4C3F8C9F.2090903@gmail.com> Hi Eric, Not that it really matters to me, but I thought I let you know, just in case you think it does matter: after sending a WINCH should you decide to send TTINs then that has no effect. ( whereas if you dropped slowly by sending TTOUs, then when it reaches 0 workers you can still send TTINs ) Cheers, Lawrence From normalperson at yhbt.net Thu Jul 15 18:40:26 2010 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 15 Jul 2010 15:40:26 -0700 Subject: Problem with x-www-form-urlencoded In-Reply-To: <6A2DBCB2-916B-49DD-A513-360494AAA73E@me.com> References: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> <20100715221402.GA31045@dcvr.yhbt.net> <6A2DBCB2-916B-49DD-A513-360494AAA73E@me.com> Message-ID: <20100715224026.GB31045@dcvr.yhbt.net> Richard Penwell wrote: > So I discovered this was a problem whereby request.body.to_s behaves > differently. I wonder if TeeStream should define to_s as an alias for > read? to_s isn't defined by any version of the Rack spec. It's horrible practice to use it, too, since it could be a big upload that uses all your memory. What are you using that does request.body.to_s? Can you change it? -- Eric Wong From normalperson at yhbt.net Thu Jul 15 18:47:03 2010 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 15 Jul 2010 15:47:03 -0700 Subject: TTIN after WINCH In-Reply-To: <4C3F8C9F.2090903@gmail.com> References: <4C3F8C9F.2090903@gmail.com> Message-ID: <20100715224703.GA32661@dcvr.yhbt.net> Lawrence Pit wrote: > Hi Eric, > > Not that it really matters to me, but I thought I let you know, just in > case you think it does matter: after sending a WINCH should you decide > to send TTINs then that has no effect. ( whereas if you dropped slowly > by sending TTOUs, then when it reaches 0 workers you can still send TTINs > ) Hi Lawrence, thanks for noticing this. Apparently nobody did before :) The following patch *should* work (untested). I'll write a proper test case later today if nobody beats me to it. diff --git a/lib/unicorn.rb b/lib/unicorn.rb index c231a4d..8f490bb 100644 --- a/lib/unicorn.rb +++ b/lib/unicorn.rb @@ -423,10 +423,12 @@ module Unicorn respawn = false logger.info "gracefully stopping all workers" kill_each_worker(:QUIT) + self.worker_processes = 0 else logger.info "SIGWINCH ignored because we're not daemonized" end when :TTIN + respawn = true self.worker_processes += 1 when :TTOU self.worker_processes -= 1 if self.worker_processes > 0 -- Eric Wong From almightylinuxgod at me.com Thu Jul 15 19:49:36 2010 From: almightylinuxgod at me.com (Richard Penwell) Date: Thu, 15 Jul 2010 19:49:36 -0400 Subject: Problem with x-www-form-urlencoded In-Reply-To: <20100715224026.GB31045@dcvr.yhbt.net> References: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> <20100715221402.GA31045@dcvr.yhbt.net> <6A2DBCB2-916B-49DD-A513-360494AAA73E@me.com> <20100715224026.GB31045@dcvr.yhbt.net> Message-ID: <7A69579A-CFCF-4FA0-896B-0D3F97191FE7@me.com> We have an application that forwards requests to staging, dev or production. So it takes the body of the request and forwards it along... Sent from my iPhone On Jul 15, 2010, at 6:40 PM, Eric Wong wrote: > Richard Penwell wrote: >> So I discovered this was a problem whereby request.body.to_s behaves >> differently. I wonder if TeeStream should define to_s as an alias for >> read? > > to_s isn't defined by any version of the Rack spec. > > It's horrible practice to use it, too, since it could be a big upload > that uses all your memory. > > What are you using that does request.body.to_s? Can you change it? > > -- > Eric Wong From lawrence.pit at gmail.com Thu Jul 15 20:47:10 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Fri, 16 Jul 2010 10:47:10 +1000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <40ECA3FF-C778-4198-B162-D2A12230D85E@tramchase.com> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> <20100714003853.GA30485@dcvr.yhbt.net> <4C3D1D7C.6010200@gmail.com> <20100714023409.GB31092@dcvr.yhbt.net> <4C3D607F.2080701@gmail.com> <40ECA3FF-C778-4198-B162-D2A12230D85E@tramchase.com> Message-ID: <4C3FAC0E.9000508@gmail.com> >> It appears unicorn rolls back by itself when it can't start the new master. Nice! >> >> Jamie also mentions to use the shared vendor/bundler_gems path. Though I do use that in all my projects I'm not so sure it's wise to do when you can't afford any downtime. I'll have to wait for unicorn v1.1.3 before I can test whether rolling back will indeed continue with unicorn v1.1.2 instead of v1.1.3 ;o >> > > Hi Lawrence, why does the shared vendor/bundler_gems cause you downtime? From not re-bundling during rollback? > > FWIW I made that recommendation because I ran into issues with unicorns not restarting correctly after running `cap deploy:cleanup`, since the `bundle exec` launches a binary with a path like /app/releases/201007125236/bin/unicorn, which goes missing after N deploys. I haven't tested if this applies to more recent versions > > Shared bundles are also significantly faster -- `bundle check || bundle install` is ~1s for me vs. several minutes to totally rebundle > Hi Jamie, I see what you mean. I haven't tested this yet, so I don't know for sure if it could cause downtime. I also always use bundle check || bundle install to get that time benefit. My worry was indeed that it might pick a newer unicorn to restart workers for the old master. I guess that can/should be prevented by having an on_rollback in my capistrano bundler task. What is the exact command you use to start unicorn? What I see is this, I start with: $ su -l deployer -c "cd /app/current ; bundle exec unicorn_rails -D -c /app/current/config/unicorn.rb" My after_fork and before_exec methods output the ENV vars to the unicorn log. I see for example: AFTER_FORK: VERSION 1 PATH=/app/releases/20100714054705/vendor/bundler_gems/bin:.... GEM_HOME=/app/releases/20100714054705/vendor/bundler_gems GEM_PATH=/app/releases/20100714054705/vendor/bundler_gems:/app/releases/20100714054705/vendor/bundler_gems/bundler/gems BUNDLE_GEMFILE=/app/releases/20100714054705/Gemfile Note that /app/releases/20100714054705/vendor/bundler_gems is a symlink to /app/releases/shared/vendor/bundler_gems When I deploy a new version, symlink /app/current to the new release directory, and send USR2 : executing ["/app/releases/20100714054705/vendor/bundler_gems/bin/unicorn_rails", "-D", "-E", "staging", "-c", "/app/current/config/unicorn.rb"] (in /app/releases/20100714055624) BEFORE_EXEC: VERSION 1 PATH=/app/releases/20100714054705/vendor/bundler_gems/bin:.... GEM_HOME=/app/releases/20100714054705/vendor/bundler_gems GEM_PATH=/app/releases/20100714054705/vendor/bundler_gems:/app/releases/20100714054705/vendor/bundler_gems/bundler/gems BUNDLE_GEMFILE=/app/releases/20100714054705/Gemfile I, [2010-07-15T23:31:47.765995 #23084] INFO -- : inherited addr=/tmp/.unicorn_sock fd=3 I, [2010-07-15T23:31:47.766646 #23084] INFO -- : Refreshing Gem list /app/releases/20100714055624/.bundle/environment.rb:175: warning: already initialized constant ENV_LOADED /app/releases/20100714055624/.bundle/environment.rb:176: warning: already initialized constant LOCKED_BY /app/releases/20100714055624/.bundle/environment.rb:177: warning: already initialized constant FINGERPRINT /app/releases/20100714055624/.bundle/environment.rb:178: warning: already initialized constant HOME /app/releases/20100714055624/.bundle/environment.rb:179: warning: already initialized constant AUTOREQUIRES /app/releases/20100714055624/.bundle/environment.rb:181: warning: already initialized constant SPECS AFTER_FORK: VERSION 2 PATH=/app/releases/20100714054705/vendor/bundler_gems/bin:.... GEM_HOME=/app/releases/20100714055624/vendor/bundler_gems GEM_PATH=/app/releases/20100714055624/vendor/bundler_gems:/app/releases/20100714055624/vendor/bundler_gems/bundler/gems BUNDLE_GEMFILE=/app/releases/20100714054705/Gemfile What you see here is that the new worker does have correct GEM_HOME and GEM_PATH values, but the PATH and BUNDLE_GEMFILE values are pointing to the old dir. Are those bundler warnings something to worry about? The BUNDLE_GEMFILE value is worrying I think. I haven't tested this, but I'm pretty sure when Bundler.setup is called within your app it will actually setup using the old Gemfile then. So that would mean you need to reset it somehow? I don't see how at the moment... should unicorn provide a method similar to +working_directory+ to help ensure the application always uses the "current" Gemfile (eg "/app/current/Gemfile") ? Sound kind of strange unicorn should provide such a method, is there another way? What about that PATH value? What happens if 10 deployments later the dir /app/releases/20100714054705 is pruned? I tried. After removing that dir I could still send a HUP, but when I send a USR2 I get this: /app/releases/20100714054705/vendor/bundler_gems/gems/unicorn-1.1.2/lib/unicorn.rb:573:in `exec': No such file or directory - app/releases/20100714054705/vendor/bundler_gems/bin/unicorn_rails (Errno::ENOENT) from /app/releases/20100714054705/vendor/bundler_gems/gems/unicorn-1.1.2/lib/unicorn.rb:573:in `reexec' > since the `bundle exec` launches a binary with a path like /app/releases/201007125236/bin/unicorn, > which goes missing after N deploys That's what I'm seeing. How did using shared vendor/bundler_gems help you? Because I'm starting with bundle exec using shared vendor/bundler_gems as well. Cheers, Lawrence From lawrence.pit at gmail.com Thu Jul 15 20:54:52 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Fri, 16 Jul 2010 10:54:52 +1000 Subject: TTIN after WINCH In-Reply-To: <20100715224703.GA32661@dcvr.yhbt.net> References: <4C3F8C9F.2090903@gmail.com> <20100715224703.GA32661@dcvr.yhbt.net> Message-ID: <4C3FADDC.70804@gmail.com> Hi Eric, Confirmed. Works for me. Lawrence >> Not that it really matters to me, but I thought I let you know, just in >> case you think it does matter: after sending a WINCH should you decide >> to send TTINs then that has no effect. ( whereas if you dropped slowly >> by sending TTOUs, then when it reaches 0 workers you can still send TTINs >> ) >> > > Hi Lawrence, thanks for noticing this. Apparently nobody did before :) > The following patch *should* work (untested). > > I'll write a proper test case later today if nobody beats me to it. > > diff --git a/lib/unicorn.rb b/lib/unicorn.rb > index c231a4d..8f490bb 100644 > --- a/lib/unicorn.rb > +++ b/lib/unicorn.rb > @@ -423,10 +423,12 @@ module Unicorn > respawn = false > logger.info "gracefully stopping all workers" > kill_each_worker(:QUIT) > + self.worker_processes = 0 > else > logger.info "SIGWINCH ignored because we're not daemonized" > end > when :TTIN > + respawn = true > self.worker_processes += 1 > when :TTOU > self.worker_processes -= 1 if self.worker_processes > 0 > From lawrence.pit at gmail.com Thu Jul 15 21:11:16 2010 From: lawrence.pit at gmail.com (Lawrence Pit) Date: Fri, 16 Jul 2010 11:11:16 +1000 Subject: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks In-Reply-To: <4C3FAC0E.9000508@gmail.com> References: <20100713201945.GB16925@dcvr.yhbt.net> <4C3D0140.6080806@gmail.com> <20100714003853.GA30485@dcvr.yhbt.net> <4C3D1D7C.6010200@gmail.com> <20100714023409.GB31092@dcvr.yhbt.net> <4C3D607F.2080701@gmail.com> <40ECA3FF-C778-4198-B162-D2A12230D85E@tramchase.com> <4C3FAC0E.9000508@gmail.com> Message-ID: <4C3FB1B4.9060504@gmail.com> > What about that PATH value? What happens if 10 deployments later the > dir /app/releases/20100714054705 is pruned? I tried. After removing > that dir I could still send a HUP, but when I send a USR2 I get this: Eric had already pointed me to http://unicorn.bogomips.org/Sandbox.html before, I forgot to add that.. this does the trick: Unicorn::HttpServer::START_CTX[0] = "/app/shared/bundler_gems/bin/unicorn_rails" Cheers, Lawrence From normalperson at yhbt.net Fri Jul 16 03:54:59 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 16 Jul 2010 07:54:59 +0000 Subject: Problem with x-www-form-urlencoded In-Reply-To: <7A69579A-CFCF-4FA0-896B-0D3F97191FE7@me.com> References: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> <20100715221402.GA31045@dcvr.yhbt.net> <6A2DBCB2-916B-49DD-A513-360494AAA73E@me.com> <20100715224026.GB31045@dcvr.yhbt.net> <7A69579A-CFCF-4FA0-896B-0D3F97191FE7@me.com> Message-ID: <20100716075458.GB30751@dcvr.yhbt.net> Richard Penwell wrote: > On Jul 15, 2010, at 6:40 PM, Eric Wong wrote: > > Richard Penwell wrote: > >> So I discovered this was a problem whereby request.body.to_s behaves > >> differently. I wonder if TeeStream should define to_s as an alias for > >> read? > > > > to_s isn't defined by any version of the Rack spec. > > > > It's horrible practice to use it, too, since it could be a big upload > > that uses all your memory. > > > > What are you using that does request.body.to_s? Can you change it? > > > We have an application that forwards requests to staging, dev or > production. So it takes the body of the request and forwards it > along... (top-posting corrected) I would always make it use a read/write loop with some fixed chunk size. If you don't care about memory usage or if you have nginx properly configured to reject large requests (the default of 1M is actually quite reasonable), then use "request.body.read" instead since that's the supported way to use all Rack apps/middlewares. You can try your apps with Rack::Lint middleware loaded during development/testing to catch these things. -- Eric Wong From mjdavies at glam.ac.uk Fri Jul 16 04:22:49 2010 From: mjdavies at glam.ac.uk (Davies Matt J A (LCSS)) Date: Fri, 16 Jul 2010 08:22:49 +0000 Subject: unsusbcribe Message-ID: <2EC7F8DF-F296-4B78-843E-BDEF30FAE554@glam.ac.uk> From normalperson at yhbt.net Fri Jul 16 04:57:11 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 16 Jul 2010 08:57:11 +0000 Subject: TTIN after WINCH In-Reply-To: <4C3FADDC.70804@gmail.com> References: <4C3F8C9F.2090903@gmail.com> <20100715224703.GA32661@dcvr.yhbt.net> <4C3FADDC.70804@gmail.com> Message-ID: <20100716085711.GA15140@dcvr.yhbt.net> Lawrence Pit wrote: > Hi Eric, > > Confirmed. Works for me. Thanks Lawrence, patch and test pushed up to unicorn.git -- Eric Wong From almightylinuxgod at me.com Fri Jul 16 09:17:56 2010 From: almightylinuxgod at me.com (Richard Penwell) Date: Fri, 16 Jul 2010 09:17:56 -0400 Subject: Problem with x-www-form-urlencoded In-Reply-To: <20100716075458.GB30751@dcvr.yhbt.net> References: <8039D754-4B3C-42FC-B7EA-642C27940897@me.com> <20100715221402.GA31045@dcvr.yhbt.net> <6A2DBCB2-916B-49DD-A513-360494AAA73E@me.com> <20100715224026.GB31045@dcvr.yhbt.net> <7A69579A-CFCF-4FA0-896B-0D3F97191FE7@me.com> <20100716075458.GB30751@dcvr.yhbt.net> Message-ID: I have used request.body.read as it's only a HTTP form post from an external provider of a fixed size. Thank you so much, I suppose I figured it out when I noticed that most of those quotes were escaped... R On Jul 16, 2010, at 3:54 AM, Eric Wong wrote: > Richard Penwell wrote: >> On Jul 15, 2010, at 6:40 PM, Eric Wong wrote: >>> Richard Penwell wrote: >>>> So I discovered this was a problem whereby request.body.to_s behaves >>>> differently. I wonder if TeeStream should define to_s as an alias for >>>> read? >>> >>> to_s isn't defined by any version of the Rack spec. >>> >>> It's horrible practice to use it, too, since it could be a big upload >>> that uses all your memory. >>> >>> What are you using that does request.body.to_s? Can you change it? >>> >> We have an application that forwards requests to staging, dev or >> production. So it takes the body of the request and forwards it >> along... > > (top-posting corrected) > > I would always make it use a read/write loop with some fixed chunk size. > > If you don't care about memory usage or if you have nginx properly > configured to reject large requests (the default of 1M is actually quite > reasonable), then use "request.body.read" instead since that's the > supported way to use all Rack apps/middlewares. You can try your apps > with Rack::Lint middleware loaded during development/testing to catch > these things. > > -- > Eric Wong From hukl at berlin.ccc.de Fri Jul 30 10:11:31 2010 From: hukl at berlin.ccc.de (hukl) Date: Fri, 30 Jul 2010 16:11:31 +0200 Subject: Autokill Workers which have grown too big Message-ID: <4C52DD93.1090900@berlin.ccc.de> Hey, at Euruko 2010 I saw a presentation where Florian Hanke presented parts of a unicorn config which killed workers once they've used up too much memory. The snipped looks like this: RackResponder = lambda do |env| possibly_commit_harakiri ... end # Commit Harakiri/Seppuku, kill yourself. # def possibly_commit_harakiri return unless commit_harakiri? Process.kill ?KILL?, Process.pid end Now I couldn't find anything about that RackResponder part on the web and was hoping that Florian himself or somebody else on the list could clue me in how that works. Also I'd like to know if there is a way to get the current memory footprint of a worker other than something like: %x(ps -o rss= -p #{Process.pid}).to_i Kind regards, John From normalperson at yhbt.net Fri Jul 30 18:06:15 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 30 Jul 2010 15:06:15 -0700 Subject: Autokill Workers which have grown too big In-Reply-To: <4C52DD93.1090900@berlin.ccc.de> References: <4C52DD93.1090900@berlin.ccc.de> Message-ID: <20100730220615.GA16267@dcvr.yhbt.net> hukl wrote: > Also I'd like to know if there is a way to get the current memory > footprint of a worker other than something like: > > %x(ps -o rss= -p #{Process.pid}).to_i Hi John, I know under Linux it's possible to parse /proc/$$/stat and also (the bigger, but more human-readable) /proc/$$/status to get current memory usage. There's also the sys-proctable gem, too, which I haven't used. -- Eric Wong From florian.hanke at gmail.com Fri Jul 30 18:32:33 2010 From: florian.hanke at gmail.com (Florian Hanke) Date: Fri, 30 Jul 2010 22:32:33 +0000 (UTC) Subject: Autokill Workers which have grown too big References: <4C52DD93.1090900@berlin.ccc.de> Message-ID: hukl berlin.ccc.de> writes: > at Euruko 2010 I saw a presentation where Florian Hanke presented parts > of a unicorn config which killed workers once they've used up too much > memory. > > The snipped looks like this: > > RackResponder = lambda do |env| > possibly_commit_harakiri ... > end > > # Commit Harakiri/Seppuku, kill yourself. # > def possibly_commit_harakiri > return unless commit_harakiri? > Process.kill ?KILL?, Process.pid > end > > Now I couldn't find anything about that RackResponder part on the web > and was hoping that Florian himself or somebody else on the list could > clue me in how that works. Hi John I thought I'd answer your question here too (not just on Github) for others to see. Perhaps someone else has similar questions. Sure. Using the RackResponder constant was just my way of naming the application. It could be any old lambda. I didn't want the GC to run and slow down any queries (in the search engine). The way the whole thing works is this: 1. The forked Unicorn child switches off the GC just after forking. unicorn.rb: after_fork do |_, _| GC.disable end 2. On each request, the child takes a look at how many requests it has already answered (or how much memory it uses, or any metric). If a threshold has been passed, it will honorably kill itself, by sending itself the QUIT signal. It will then finish responding the request and die. A Rack middleware for the request counting metric can be found here: http://bit.ly/bjkbRG 3. The Unicorn master process notices that a child has gone and forks a new one. 4. The OS ? rather than the GC ? cleans up the memory mess left by the dead child ;) > Also I'd like to know if there is a way to get the current memory > footprint of a worker other than something like: > > %x(ps -o rss= -p #{Process.pid}).to_i On Linux, the /proc folder holds a lot of information on the currently running processes. One can for example use cat /proc/some_proc_id/statm to get Memory information. Cheers and have fun, Florian