I advanced a lot, and despite not being able to access env vars, I found
the way to distinguish the adopted vassals between each other - by process
uid. That was sufficient for my usecase.
I also tried to access "uwsgi.opt" values from shared-pyimport script, but
it had the values of the base vassal, ignoring anything set in the adopted
one's .ini file.

Now cannot make this work nicely with emperor-on-demand
(socket-activation), because the emperor does not spawn the base vassal,
cause it's waiting for someone to connect to it.
The adopted ones do not start until I manually connect to base's socket to
launch it, only then it starts listening on fork-socket.

As a result,
the amount of shared memory (I find it out by the Pss entry in
/proc/pid/smaps) unfortunately greatly reduces after the configuration
fixups and the first request, so the result is not that noticeable.
And somehow the vassals get stuck on loading sometimes and do not print
"vassal is ready to accept requests", and the requests to them freeze
forever. Yet to debug why.

Thanks!


On Thu, Jun 26, 2014 at 7:41 PM, Igor Katson <[email protected]> wrote:

> Thanks for your answers, the only issue left is with "env" or "ienv" still
> not working for the adopted vassals.
>
>
>>  > 3. I have large uwsgi configs for the vassals. Which of these settings
>> > should I move to the "base" vassal, and which of them are supposed to
>> work
>> > in the base vassal at all?
>> > https://gist.github.com/ikatson/1a13fdb8a5606258e783.
>>
>> if you are using a django app, lazy-apps is not needed (django is lazy by
>> default). The purpose of the base server is load the app and then wait for
>> fork, so i would only place early-pyimport (one for every module required)
>>
> I use django, but with a heavily modified wsgi script, it's hard to say
> what's lazy there. In the end, I'll need to hack things up to replace some
> django settings, that already got loaded, with the per-app settings that I
> want. The whole purpose of using the fork-server for me is to import as
> many python modules as possible (i.e. load every one of INSTALLED_APPS),
> and fork only after that. Some of these modules depend on django settings,
> and do not expect them to change.
>
>
>>  > 4. Both base and adopted vassals seem to ignore the environment
>> variables.
>> > How do I pass them? Can I supply addition environment variables to the
>> > adopted vassals for configuration?
>>
>> ienv for the base (before early-*), env in vassals should work normally
>>
>
> Unfortunately, neither "ienv" not "env" helps for the adopted ones, they
> all seem to use the environment variables of the base vassal. "ienv" for
> base vassal works though.
>
> I also got 2 issues:
>
> 1. An adopted vassal's logfile filled up with this line suddenly killed
> all my disk space (tens of gigabytes), without any error messages in the
> emperor log. That happened only once, and I couldn't reproduce it.
> uwsgi_master_manage_events()/read(): Transport endpoint is not connected
> [core/master_events.c line 212]
>
> 2. Absolutely the same situation, another logline filling up the logs
> indefinitely, but this was kind of reproducible.
> epoll_wait(): Invalid argument [core/event.c line 704]
>
> After a zillion flaky attempts, it looks I figured out the pattern, the
> error disappeared when I added "http=ip:port" to the config. There was no
> "socket" line there either before that. But not sure, if it was the true
> reason, and if I resolved it completely.
>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to