From my own experience [and less than firm enough recommendations in
the docs] I always start my ini files with "strict = true". This will
make uWSGI raise an error if it finds an option in the ini file it does
not recognise, instead of treating it as a user-defined variable.
I also never rely on the Debian init scripts [or unit file, or what have
you] to launch my uwsgi sites, for 3 reasons:
1. I find it simpler to use the one provided in the uWSGI docs
2. I want to avoid the "unknown" options Debian's pre-config sets
3. I always run an Emperor, so no need for a lot of what Debian provides.
From memory, it _is_ possible to install the Debian packages and not
get the init script. It may even be mentioned in my docs on setting up
a simple Django site. I think it's the difference between "uwsgi" and
"uwsgi-core".
Lastly, only debian testing has a 'current' version of uWSGI, so I tend
to install from pip anyway... typically only providing the plugins I need.
However, yes, the docs are always lacking. input is always welcomed, I
find.
--
Curtis
On 10/10/2017 10:24 PM, Bernd Wechner wrote:
I just spent hours, on this and more than a little frustrated by it all.
But I implemented a uwsgi site with python and django and I wrote a .ini
file and I run it with "uwsgi my.ini" see a beautiful console trace and
my website works. It talks to lighttpd over a unix domain socket. Happy
chappy, nice site.
Now the uwsgi package on Debian derivatives is nice in that it also
installs a uwsgi service and app I have to do is put my .ini file in:
/etc/uwsgi/apps-enabled
and then and restart the service ("service uwsgi restart" works, as does
"/etc/init.d/uwsgi restart" and "systemctl start uwsgi" because Ubuntu
systems are now running under systemd which maintains backward
compatibility with other init services, but that is a digression, they
all do the same thing) and my web site though is defunct. No service
available.
The log file reports an endless stream of worker deaths and respawns,
workers dying because they fail to load the mono plugin. What? I have
nothing to do with mono here. I mean I like mono and am a C# developer
even, but hey, this webserver hasn't come close to mono in any way shape
or form. What gives? And why?
To cut a long story short, loads of tracing effort and step throughs and
tests later, it boils down to the fact that service loads another .ini
file prior to mine (/usr/share/uwsgi/conf/defaul.ini) and in that file
this one line:
# try to autoload appropriate plugin if "unknown" option has been specified
autoload = true
is to blame. If I comment it out, my website runs fine with uwsgi as a
service now. But autoload if true, wants to load the mono plugin! Why?
The documentation is meagre saying only:
autoload
Try to automatically load plugins when unknown options are found.
(see https://uwsgi-docs-additions.readthedocs.io/en/latest/Options.html).
So it seems it' finding an unknown option, and thinks mono is needed for
that option?
So to check what the source of this unknown option might be, I put
"autoload = true" into my.ini and ran it manually. Website works fine,
no attempt to load the mono plugin.
So the source of the unknown option must be default.ini which contains:
master = true
autoload = true
workers = 2
no-orphans = true
pidfile = /run/uwsgi/%(deb-confnamespace)/%(deb-confname)/pid
socket = /run/uwsgi/%(deb-confnamespace)/%(deb-confname)/socket
chmod-socket = 660
log-date = true
uid = www-data
gid = www-data
(comments removed). Which of those options might be suggesting to uwsgi
that the mon plugin is needed? Bizarre as!
Now I have a working setup by removing "autoload = true" from the
default.ini, but I am driven by a desire to understand what caused this
bizarre behaviour that robbed me hours of my life to diagnose, and fix!
I could, play around a little more still, knocking out one line after
another from default.ini to see if it still wants to load the mono
plugin. Maybe, if I make time for it. Time for bed now ;-).
What I think is lacking is:
1) Good documentation on what autoload loads and why (what triggers a
load, i.e. is seen as an unknown option that needs a given module, or
whatever else drives it)
2) A way to diagnose what it would load? Maybe not "autoload = true",
but a directive ("autoload = transparent") to print on stdout (or to log
file) the modules it wants to load and why!
3) Given how darned irritatingly time consuming tracing this has been,
there is no reason I can see that "autoload = true" should be packaged
into the Debian package for uwsgi. I see it as totally find for end
users to explicitly load the plugins they need (I explicitly have
"plugins = python3" in my.ini).
Good night, and thanks in advance for any constructive and insightful
responses should they come,
Bernd.
_______________________________________________
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
