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 latest releases. 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 <[email protected]> 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 [1] > > [1] 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 >> exact. >> >> 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? >> >> Thanks! >> -Paul >> > > -- > [email protected] > http://unixwars.com/ > > _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
