http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3692 <pre>Nice! I'll try this now, many thanks :) Cal On Fri, May 25, 2012 at 2:10 PM, Roberto De Ioris &lt;roberto-5KDOxZqKugI&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ uWSGI mailing list uWSGI-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Cal Leeming [Simplicity Media Ltd] 2012-05-25T17:01:01 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3691 <pre> Il giorno 25/mag/2012, alle ore 15:00, Cal Leeming [Simplicity Media Ltd] ha scritto: --reload-on-exception (no arguments) -- Roberto De Ioris http://unbit.it JID: roberto-hbUbo2vRRWeuzzpfBbZE4A&lt; at &gt;public.gmane.org </pre> Roberto De Ioris 2012-05-25T13:10:47 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3690 <pre>Seems that we didn't get any more 'status code 415' errors, but we did get some others. Is there a way to make it reload on all exceptions?? Cal On Wed, May 23, 2012 at 8:24 PM, Roberto De Ioris &lt;roberto-5KDOxZqKugI&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ uWSGI mailing list uWSGI-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Cal Leeming [Simplicity Media Ltd] 2012-05-25T13:00:36 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3689 <pre> Yes i am reindenting part of the code. </pre> Roberto De Ioris 2012-05-24T19:00:34 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3688 <pre>Dnia czwartek, 24 maja 2012 20:34:38 Roberto De Ioris pisze: It looks like something else got also commited: http://projects.unbit.it/uwsgi/changeset/efdf4307873faa437a3e14c1043a0ec4096bdcec But it looks like it's mostly tabs and spaces being swapped, and no code was harm. Łukasz Mierzwa _______________________________________________ uWSGI mailing list uWSGI&lt; at &gt;lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Łukasz Mierzwa 2012-05-24T18:41:54 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3687 <pre> Applied, thanks </pre> Roberto De Ioris 2012-05-24T18:34:38 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3686 <pre> applied, thanks </pre> Roberto De Ioris 2012-05-24T18:29:55 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3685 <pre>Hello, check if __sun__ and __APPLE__ are actually defined and not what they are defined to. thanks, riccardo _______________________________________________ uWSGI mailing list uWSGI-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Riccardo Magliocchetti 2012-05-24T18:12:58 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3684 <pre>Hello, check if __sun__ and __APPLE__ are actually defined and not what they are defined to. thanks, riccardo </pre> Riccardo Magliocchetti 2012-05-24T18:12:12 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3683 <pre>Thanks for the response. I think I had a confusion. I only wanted the logging to redirect to a file and I was using daemonize for that. I later found the logto directive which I think is cleaner and simpler for my purposes. I also learned that you can redirect stderr and stdout directly in the upstart exec script. Thanks, Danny From: uwsgi-bounces-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org [mailto:uwsgi-bounces-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org] On Behalf Of nick hatch Sent: Wednesday, May 23, 2012 5:08 PM To: uWSGI developers and users list Subject: Re: [uWSGI] newbie question with daemonize and too many uwsgi processes On Wed, May 23, 2012 at 4:48 PM, Shevitz, Daniel W &lt;shevitz-YOWKrPYUwWM&lt; at &gt;public.gmane.org&lt;mailto:shevitz-YOWKrPYUwWM&lt; at &gt;public.gmane.org&gt;&gt; wrote: Notice "-p 1" I believe this should give me one process, which in fact it does. I know this from the output of "ps -A |grep uwsgi" But if I add the flag --daemonize /opt/log/uwsgi/uwsgi.log And then run "ps -A|grep uwsgi" I have ten processes </pre> Shevitz, Daniel W 2012-05-24T15:09:02 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3682 <pre>With rev 2228 [1] carbon stats for workers can be skipped, it works fine but using this option also disables total rss size, vsz size and avg response time metrics that are calculated by iterating per worker stats. I've made a quick patch, please take a look at it. [1] - http://projects.unbit.it/uwsgi/changeset/ebde5e6b88cdc590e3b9c53cc2a65709117d8acb Łukasz Mierzwa_______________________________________________ uWSGI mailing list uWSGI-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Łukasz Mierzwa 2012-05-24T13:00:36 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3681 <pre>Hi Daniel, On Thu, May 24, 2012 at 1:07 AM, nick hatch &lt;nicholas.hatch-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: I haven't worked with Upstart in Ubuntu but I usually use -M and -p options in uWSGI. The first one provides a Master process and the second one specifies how many workers do you want. So you will have a Master uWSGI process with n workers. If you kill the master, all workers will die too. I hope this helps you. Regards, Manu. </pre> Manuel F. Viera 2012-05-24T12:44:04 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3680 <pre>Dnia czwartek, 24 maja 2012 12:10:01 Roberto De Ioris pisze: Little better - master still gets looped, but it doesn't eat as much cpu as before (only 1 core this time ;), strace: [...] [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 22401] wait4(-1, 0x7fff987305e8, WNOHANG, NULL)</pre> Łukasz Mierzwa 2012-05-24T10:22:17 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3679 <pre> Il giorno 24/mag/2012, alle ore 11:46, Łukasz Mierzwa ha scritto: Can you retry the latest tip ? I was not able to reproduce the problem, but from you strace looks like we need an additional check. Let me know -- Roberto De Ioris http://unbit.it JID: roberto&lt; at &gt;jabber.unbit.it _______________________________________________ uWSGI mailing list uWSGI&lt; at &gt;lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Roberto De Ioris 2012-05-24T10:10:01 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3678 <pre>Dnia czwartek, 24 maja 2012 11:32:16 Łukasz Mierzwa pisze: Same thing with 1.3-dev-2329, once my workers are killed by --idle option, master starts to eat cpu. It seems that it just gets looped trying to kill subprocess with "-1" pid. Stracing master shows: [...] [pid 20242] wait4(-1, 0x7fff58236a98, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 20242] write(2, "subprocess -1 exited by signal 9"..., 33 &lt;unfinished ...&gt; [pid 20244] &lt;... poll resumed&gt; ) = 1 ([{fd=4, revents=POLLIN}]) [pid 20244] read(4, "subprocess -1 exited by signal 9"..., 8192) = 33 [pid 20244] sendto(24, "&lt;29&gt;May 24 11:46:02 onion: subpr"..., 59, 0, {sa_family=AF_INET, sin_port=htons(514), sin_addr=inet_addr("127.0.0.1")}, 16) = 59 [pid 20244] poll([{fd=4, events=POLLIN}], 1, -1 &lt;unfinished ...&gt; [pid 20242] &lt;... write resumed&gt; ) = 33 [pid 20242] wait4(-1, 0x7fff58236a98, WNOHANG, NULL) = -1 ECHILD (No child processes) [pid 20242] write(2, "subprocess -1 exited by signal 9"..., 33 &lt;unfinished ...&gt; [pid 20244] &lt;.</pre> Łukasz Mierzwa 2012-05-24T09:46:53 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3677 <pre>Dnia czwartek, 24 maja 2012 11:30:33 Roberto De Ioris pisze: (Stripping trailing CRs from patch.) patching file master.c Hunk #1 succeeded at 312 (offset -2 lines). Hunk #2 succeeded at 754 (offset -3 lines). Hunk #3 succeeded at 1198 (offset -3 lines). No conflicts, but I will try with fresh tip. Łukasz Mierzwa _______________________________________________ uWSGI mailing list uWSGI&lt; at &gt;lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Łukasz Mierzwa 2012-05-24T09:32:16 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3676 <pre> Il giorno 24/mag/2012, alle ore 11:09, Łukasz Mierzwa ha scritto: Are you sure the patch correctly applies to 1.2 ? it is pretty "messy" as i have removed a bunch of checks too -- Roberto De Ioris http://unbit.it JID: roberto&lt; at &gt;jabber.unbit.it _______________________________________________ uWSGI mailing list uWSGI&lt; at &gt;lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Roberto De Ioris 2012-05-24T09:30:33 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3675 <pre>Dnia środa, 23 maja 2012 20:41:55 Roberto De Ioris pisze: With 1.2.3 + this patch master process eats a lot of cpu and my logs shows: May 24 11:01:35 subprocess 8 exited with code 0 May 24 11:01:35 subprocess -1 exited with code 0 May 24 11:02:06 last message repeated 293577 times May 24 11:03:07 last message repeated 466430 times May 24 11:04:08 last message repeated 496155 times Łukasz Mierzwa _______________________________________________ uWSGI mailing list uWSGI&lt; at &gt;lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Łukasz Mierzwa 2012-05-24T09:09:05 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3674 <pre> This sounds like it might be a problem with your upstart config, as you're not specifying 'expect daemon'. [1] Unless you have a specific reason to daemonize uwsgi, I'd avoid it. Upstart jobs are much easier to manage if they don't detach, as you don't need to worry about fork counting and other messy details. -n [1] http://upstart.ubuntu.com/cookbook/#daemon-behaviour _______________________________________________ uWSGI mailing list uWSGI-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> nick hatch 2012-05-23T23:07:45 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3673 <pre>Howdy, I am just learning how to use uwsgi and have a sample django application running under Nginx. I am running from an Upstart script on Ubuntu. My Upstart script I lifted from the web from Jeremy Bowers: description "uWSGI server for Project Foo" start on runlevel [2345] stop on runlevel [!2345] respawn exec /usr/sbin/uwsgi --socket /opt/run/foo.sock\ --chmod-socket --module wsgi_app\ --pythonpath /opt/django-projects/foo/uwsgi\ -p 1 Notice "-p 1" I believe this should give me one process, which in fact it does. I know this from the output of "ps -A |grep uwsgi" But if I add the flag --daemonize /opt/log/uwsgi/uwsgi.log And then run "ps -A|grep uwsgi" I have ten processes running. I assume this a feature, not a bug. So how do I control the number of processes running in daemonize mode? Thanks, Danny _______________________________________________ uWSGI mailing list uWSGI-FfzAktRlpg7/cILp9QSAqw&lt; at &gt;public.gmane.org http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi </pre> Shevitz, Daniel W 2012-05-23T21:48:47 http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/3672 <pre> I will make a report for him tomorrow. Does the reload-on-exception trick helped ? </pre> Roberto De Ioris 2012-05-23T19:24:58 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.wsgi.uwsgi.general