Oh, that's such a coincidence! I've looked through the changelogs searching for anything similar being fixed in later revisions, but did not find any clues. So I thought that keeping with the older version is fine.
Again, by coincidence, my dev setup contained the same 1.9.18 version. Thanks a lot for, Roberto, this really helped! On Tue, Nov 19, 2013 at 8:49 PM, Roberto De Ioris <[email protected]> wrote: > > > Here are the logs of when the vasal is reloaded. > > https://gist.github.com/ikatson/7552265 > > > > requests, that got 502 errors where performed to the URLs, that are not > > even mentioned in this log. > > > > Subsequent successful requests start the log over like this: > > > > *** Starting uWSGI 1.9.18.2 (64bit) on [Tue Nov 19 20:44:42 2013] *** > > compiled with version: 4.6.3 on 23 October 2013 03:45:04... > > > > Thank you in advance, Roberto. > > > You have hit a bug in 1.9.18 (fixed in 1.9.19) where on reload the master > attempt to place itself in the cgroup again (obviously without having > permission). From 1.9.19 this step is skipped on reload. > > > > > > > On Mon, Nov 18, 2013 at 9:44 PM, Roberto De Ioris <[email protected]> > > wrote: > > > >> > >> > Hi, > >> > > >> > I'm using the emperor-on-demand setup. > >> > Some time ago, I was not having any 502 errors from nginx on > >> reloading. > >> > > >> > I have 134 vassals running under that emperor (though at a point in > >> time, > >> > usually about 20 is up, all the others are waiting for socket > >> > connections). > >> > > >> > Recently, 502 errors started appearing for a few seconds on touching > >> the > >> > vassal's ini file. > >> > > >> > Before that, the first request was just taking a while, but not > >> showing > >> > any > >> > 502 errors. > >> > > >> > I don't know what exactly is causing this, that might be the amount of > >> > vassals, but it seems it's not, cause I can reproduce this on the dev > >> > machine with only a couple of vassals. There were too many code > >> changes, > >> > and it's almost impossible to find a changelist, which possibly > >> introduced > >> > this (if it is in the python code). > >> > > >> > However, nothing at all about missed requests is found in the uwsgi > >> logs. > >> > Which makes me think the problem is somewhere within the uwsgi > >> > integration. > >> > > >> > Here's the message from nginx logs. > >> > > >> > 2013/11/19 03:33:42 [error] 9158#0: *1337160 recv() failed (104: > >> > Connection > >> > reset by peer) while reading response header from upstream, client: > >> > 144.76.72.178, server: , request: "GET ......... > >> > > >> > The error is only visible for a few seconds after the reload, if you > >> > refresh the page instantly after the reload. If no requests are made > >> at > >> > all > >> > after the reload, and the first request comes in e.g. 10 seconds after > >> the > >> > reload, there are no 502 errors. > >> > > >> > - uwsgi version is 1.9.18 > >> > - config files are here https://gist.github.com/ikatson/7524404 > >> > > >> > What can be causing this behavior, and where can I dig to fix it? > >> > > >> > Also, the same happens for a much longer period of time on restarting > >> the > >> > emperor, though, I understand, that this probably cannot be handled. > >> > > >> > Thanks! > >> > _______________________________________________ > >> > uWSGI mailing list > >> > [email protected] > >> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > >> > > >> > >> Can you report the logs of a vassal when reloaded ? > >> > >> Generally when 502 happens on reload it means the vassal has been > >> destroyed during reload (for some configuration/privileges problems) and > >> the emperor suddenly restarted it. > >> > >> -- > >> Roberto De Ioris > >> http://unbit.it > >> _______________________________________________ > >> uWSGI mailing list > >> [email protected] > >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > >> > > _______________________________________________ > > uWSGI mailing list > > [email protected] > > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
