ok, i submitted a ulimit patch: https://github.com/Supervisor/supervisor/pull/229
On Wed, Aug 22, 2012 at 3:52 PM, David Birdsong <[email protected]>wrote: > i needed ulimit support pretty badly > 1 year ago, so i copy pasted > code for the parent process into a program setup. > > was useful for all setrlimits: > - numprocs > - numfiles > - stack size > > the patch is really ugly and is hard to maintain against newer > versions of supervisord, so i'd love for a better patch to surface. > > On Wed, Aug 22, 2012 at 10:20 AM, Jason Koppe <[email protected]> wrote: > > I'm still keen on seeing ulimit support added. Anyone else working on > this > > in a fork? > > > > On Thu, Sep 9, 2010 at 12:17 PM, Jason Koppe <[email protected]> wrote: > >> > >> We're using a wrapper around supervisorctl right now to accomplish > custom > >> ulimits, but this clearly isn't ideal. > >> > >> > >> On Thu, Sep 9, 2010 at 11:40, Jason Koppe <[email protected]> wrote: > >>> > >>> I'd love ulimit or pam support, too! > >>> > >>> On Thu, Sep 9, 2010 at 11:34, Jordan Sissel <[email protected]> wrote: > >>>> > >>>> Howdy howdy, > >>>> > >>>> I've been using supervisor for a few weeks (moving from previously > using > >>>> daemontools), and I have a growing list of stuff I'd like to see in > the > >>>> project and would be happy to code and contribute myself - the docs > say to > >>>> email the list if I'm interested in contributing, so here's my > feature list > >>>> in no particular order: > >>>> > >>>> - ulimit support. supervisord doesn't invoke pam so it ignores > >>>> /etc/security/limits.conf on Linux systems. Further, I would like to > specify > >>>> ulimit values per-program. > >>>> - 'startretries=unlimited' would be excellent. I work around this by > >>>> setting startretries=1000000, but it's not ideal since '1000000' > doesn't > >>>> explain my intent. > >>>> - Want a built-in way to send signals. That is, I want 'supervisorctl > >>>> signal <process> HUP' because many things support such signals for > reloading > >>>> config files, etc. Current workaround is to use 'supervisorctl pid > <thing> | > >>>> awk | xargs kill -SIGNAL' which isn't very awesome. > >>>> - As far as I can tell, there is no way to force a process out of > >>>> 'backoff' state. I have tried 'restart' and other commands. Having > this > >>>> ability would be good. > >>>> - I also don't see a way to tune backoff timeouts, etc. > >>>> - I want logs with timestamps. Not all programs output messages with > >>>> timestamps. daemontools had 'multilog' for this kind of thing that > would > >>>> prefix process output with timestamps (among other things) > >>>> - the event notification stuff could be nicer with a sample python > >>>> library implementation to save some folks from the details of the wire > >>>> protocol between supervisor and event handlers. > >>>> > >>>> Apologies if some of the above features are already implemented and > >>>> documented. I tried to be thorough in my reading of the (very) awesome > >>>> documentation this project has before making this list. :) > >>>> > >>>> > >>>> -Jordan > >>>> > >>>> _______________________________________________ > >>>> Supervisor-users mailing list > >>>> [email protected] > >>>> http://lists.supervisord.org/mailman/listinfo/supervisor-users > >>>> > >>> > >>> > >>> > >>> -- > >>> Jason Koppe > >>> [email protected] > >>> (210) 445-8242 > >> > >> > >> > >> > >> -- > >> Jason Koppe > >> [email protected] > >> (210) 445-8242 > > > > > > > > > > -- > > Jason Koppe > > [email protected] > > (210) 445-8242 > > > > _______________________________________________ > > Supervisor-users mailing list > > [email protected] > > http://lists.supervisord.org/mailman/listinfo/supervisor-users > > >
_______________________________________________ Supervisor-users mailing list [email protected] https://lists.supervisord.org/mailman/listinfo/supervisor-users
