On Fri, Jul 8, 2011 at 3:18 PM, Cal Leeming [Simplicity Media Ltd] <cal.leem...@simplicitymedialtd.co.uk> wrote: > On Fri, Jul 8, 2011 at 3:13 PM, Tom Evans <tevans...@googlemail.com> wrote: >> On Fri, Jul 8, 2011 at 3:04 PM, Cal Leeming [Simplicity Media Ltd] >> <cal.leem...@simplicitymedialtd.co.uk> wrote: >>> Although I'm sure both methods would work, would you recommend any >>> particular preference? (as my preference is merely on the fact that >>> having a wrapper seems a lot cleaner). >>> >>> I guess the custom binary I was trying to think of earlier used the >>> setrlimit/fork method mentioned above. >> >> There is only one way to modify limits, and that is setrlimit, which >> is how ulimit is implemented. Given ulimit and setrlimit are both in >> POSIX, I don't see why anyone would write their own wrapper to do >> this. > > My worries were that in the event of children processes spawning some
processes spawning from* > a single parent, both executing ulimit, there could potentially be a > race condition. > > For example: > > shell >> supervisord (forks, and shell exits) > > calls nginx-wrapper > > calls ulimit > > calls nginx > > calls other-wrapper > > calls ulimit > > calls other > > In the above scenario, ulimit would apply that limit to everything > within that forked supervisord instance, correct? > > Therefore, if nginx-wrapper calls ulimit at almost the exact same > point as other-wrapper, there could be a race condition between the > time it takes to jump from ulimit to the binary, where the wrong > address space is inherited. > > Or have I understood that wrong?? > >> >> The way I typically add limits is to edit the rc (startup) script, and >> add a call to ulimit there. This applies the limit to the process >> which launches the daemon, its a simple clean one liner, and doesn't >> require massaging command line arguments into a sh -c '' line (or >> bash). >> >> Cheers >> >> Tom >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
