Re: Cherokee startup from cherokee-admin and setting environmental variables
pub crawler <pubcrawler.com <at> gmail.com>
2009-10-02 19:00:08 GMT
Thanks for responding Taher,
Cron job was our first idea - we have lots of cron tasks already
munging various things and sanitizing our environment - like checking
for certain temp sub directories exist. Since I am unsure exactly what
determines the runtime values for Cherokee and having heard from
Alvaro that Cherokee attempts to bump the ulimit at start time I
thought it was best to make sure the ulimit was artificially high
already when Cherokee starts up.
Since our issue with the 503s is a runtime environmental value thought
it was best to link the ulimit increase/set to when Cherokee is
started from the admin.
I would hate to mess with Cherokee code as we often upgrade to the
Perhaps a setting in the admin for ulimit for open files would be the
good middle ground?
BTW: Ulimit issues are fairly common with many similar software
packages. Cherokee assumes a lower knowledge point to entry with the
simplified admin GUI. Having people run into the 503 error due to
ulimit is per se preventable by configuring the environmental variable
in the admin and pruning connections when limit hit. We could even
note the limit ceiling hit and put a message then in admin about
increasing the ulimit.
On Fri, Oct 2, 2009 at 2:01 PM, Taher Shihadeh <taher <at> unixwars.com> wrote:
> Excuse me if I'm missing the point and the answer seems simplistic. We will
> have to correctly deal with the 503 problem eventually, but answering the
> question about the workaround you are looking for: Wouldn't it be simpler
> just to have a cron task pumping ulimit values and gracefully restarting via
> the appropriate signal? Seems much more straight forward to me than making
> changes to the admin.
> You can, of course, rewire cherokee-admin and add whatever you please. Any
> logic on how it restarts the server can be found in
> admin/CherokeeManagement.py, which, by the way, is simply issuing the SIGHUP
> or SIGUSR1 signals mentioned in the documentation 
>  http://www.cherokee-project.com/doc/other_signals.html
> pub crawler wrote:
>> Good day everyone!
>> Still wrestling with ulimit values causing Cherokee to 503 error crash.
>> Our solution has been to set ulimit for open files higher - to 9000 to be
>> That has worked for a few weeks. However, we were smacked by the 503
>> error again today. What happened is simple, I turned Keep Alive back
>> on and ulimit for open files was 1024. Unsure why ulimit was set to
>> 1024 again. So open file resources were eventually exhausted, never
>> released and Cherokee kept sending a 503. We long term need to build
>> intelligence into Cherokee to prune open kept alive connections when
>> such a resource contention exists.
>> For now, I need input on a workaround so we never get 503'd by this
>> again. Here's what I propose:
>> We use cherokee-admin to run and restart Cherokee fairly often. We try
>> to avoid manually running Cherokee unless we really have to for some
>> reason like testing a specific release.
>> Is there a way to append to logic to the LAUNCH handler on the main
>> admin screen? When I click launch I want Cherokee to go ahead and step
>> up the ulimit as insurance that the environment it is running in has
>> same limits every time.
>> Anyone have any ideas about this or better way to accomplish this?
> taher <at> unixwars.com