our logging broke after a redeployment and I can't seem to figure out what is
going on. The loglevel keeps dropping to DEBUG as if nothing is configured.
(it's support to be ERROR or CRITICAL)
our stack looks like this:
1. supervisord invokes uwsgi
/var/www/sites/virtualenv/bin/uwsgi
Thanks for looking, robert.
the uwsgi log looks like this:
*** Starting uWSGI 2.0.15 (64bit) on [Tue May 16 16:22:13 2017] ***
compiled with version: 5.4.0 20160609 on 15 May 2017 19:45:42
os: Linux-4.9.15-x86_64-linode81 #1 SMP Fri Mar 17 09:47:36 EDT 2017
nodename: sextant
mach
after a few hours we finally figured it out.
a random package had this line in it:
logging.getLogger().setLevel(logging.DEBUG)
that only took... 5 hours to find after writing a few virtualenvs/services to
try and replicate this.
___
uWSGI m
can you share the output of "pip freeze"?
On May 17, 2017, at 3:20 AM, Gerhard Schmidt wrote:
>
> Noting the ImportError I started to Google and found that i should
> install PasteDeploy and PasteScript.
>
> After installing both and restarting i get a differen ImportError
> ImportError: No modu
paste, pastescript and pastedeploy in my virtualenv
2. when trying to recreate your issue, I personally ran into problems with
permissions of python packages.
On May 18, 2017, at 1:15 AM, Gerhard Schmidt wrote:
> Am 17.05.2017 um 18:52 schrieb jonathan vanasco:
>> can you share the output
we have a few HTTP endpoints that have very large request payloads (headers +
query string). They’re all oAuth endpoints coming in from 3rd parties, with a
bunch of header data and a super long query string.
the quick fix was to double buffer-size to 8192
is this the best approach?
also, it
> On Feb 14, 2018, at 1:08 PM, jonathan vanasco wrote:
>
> also, it might be worth adding to the “ThinkToKnow” docs that if you’re doing
> anything with oAuth against twitter or Facebook, you should increase the
> buffer size. one (or more) platforms had some recent ch
has anyone here run into a problem where making a call to urllib2.open(any_url)
will crash uwsgi without any error in python, and the uwsgi log has
DAMN ! worker 1 (pid: 7600) died, killed by signal 10trying respawn ...
this happens within 2-4 seconds. i tried setting --socket-timeout an
On Jun 13, 2012, at 9:26 AM, Roberto De Ioris wrote:
> I think i have answered some hours ago on the pyramid/pylons list.
> Are you sure you have not enabled some memory constraint ?
>
> You have not reported the uWSGI configuration, can you post it ?
Oh thank you for posting there. I see that
On Jun 13, 2012, at 10:10 AM, Roberto De Ioris wrote:
> Do you redefine/use SIGUSR1 in your app ?
>
> The worker is killed by the delivery of SIGUSR1, and this is not triggered
> by uWSGI
Are you sure it's SIGUSR1 , and not Signal 10 ( Bus error | SIGBUS ) ?
>DAMN ! worker 1 (pid:
On Jun 24, 2012, at 12:38 PM, Roberto De Ioris wrote:
> * Smarter OSX universal binary management
>
> on some OSX setup, building uWSGI can be a real mess thanks to universal
> binary management. This patch should reduce the problem a bit (at least
Hi Roberto-
I ran into trouble building on OS
Hi.
I originally deployed a Pyramid app in production like this:
nginx -> uwsgi -> pryamid
uwsgi is for the app started with this `uwsgi --options` command
That was great, but my needs changed as I've had to launch new applications on
the same server. I'm a bit confused with all the o
d your 3+
> app setup I would set up paired masters for each so that I could do
> graceful reloads on a single app or the whole stack depending on what
> had changed.
>
> My two pesos semi custom to our stack, but hope its useful.
> _
On May 30, 2013, at 7:06 PM, Alberto Scotto wrote:
> But in your case Emperor is not enough: for managing Sentry you have to use
> supervisor (there isn't a uWSGI plugin for it, as far as I know), as stated
> in Sentry's docs:
> http://sentry.readthedocs.org/en/latest/quickstart/index.html#run
On Jun 4, 2013, at 8:08 PM, Alberto Scotto wrote:
> Well for your problem of having 15 processes, maybe you just need to have a
> look at processes option
>
> PS: the one I sent before was the conf for uWSGI Emperor+FastRouter managed
> by supervisor.
> And here is the the real INI conf with u
15 matches
Mail list logo
