nginx uwsgi error 502 bad gate way

[Lewis]

Guys, I have followed the cookbook, the posts here, and a posting at stackoverflow.

I am getting error 502 bad gateway.  My stuff looks like everyone else's but there are deeper layers of indirection in uwsgi itself and nginx.  I have several uwsgi sym links in /etc/init.d    It is not clear which is the "real" one and how to invoke it.

Here is the error from the nginx log.  I guess I interpret this to mean that nginx can't find uwsgi:

2012/05/16 22:53:29 [error] 2460#0: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 76.104.195.84, server: www.lewcl.com, request: "GET / HTTP/1.1", upstream: "uwsgi://127.0.0.1:9001", host: "www.lewcl.com"

I have no clue what to do.

Guys, I think that python and web2py have a profoundly serious problem with config.  Documentation is often wrong--a single punctuation mark, directory or option being off means it won't work.  If we have that in our Python code it won't run, but we have great traceback and debugging tools to tell us exactly where the error is and often what the error is. But when one of 5 or 6 text files scattered across the file system is wrong, all we find out is that it won't run.  There are no diagnostics (or very course ones like "error").  I'd like to work with some people in the community to redo a lot of the guides and get them to be accurate.

I don't think script files are much of a solution (except as a way to document something that once worked on some arbitrary system).  Running an arbitrary script file blindly can do serious harm to your environment.   Script files are not fully debugged and recoverable setup programs.  "Setup" is one of the hardest things to do right.  It is not a throw-away task to be done at the end of the project.

[pbreit]

I'd agree that Python deployment remains unnecessarily difficult.

I also agree that just running random scripts isn't the best approach. However I think it can be very helpful to run the commands manually that you find in a script. Then you really know what is being performed and can create your own scripts.

In terms of figuring out your problem, might be useful to see relevant parts of nginx.conf.

[Roberto De Ioris]

> Guys, I have followed the cookbook, the posts here, and a posting at
> stackoverflow.
>
> I am getting error 502 bad gateway. My stuff looks like everyone else's
> but there are deeper layers of indirection in uwsgi itself and nginx. I
> have several uwsgi sym links in /etc/init.d It is not clear which is
> the
> "real" one and how to invoke it.
>
> Here is the error from the nginx log. I guess I interpret this to mean
> that nginx can't find uwsgi:
>
> 2012/05/16 22:53:29 [error] 2460#0: *1 connect() failed (111: Connection
> refused) while connecting to upstream, client: 76.104.195.84, server:
> www.lewcl.com, request: "GET / HTTP/1.1", upstream:
> "uwsgi://127.0.0.1:9001", host: "www.lewcl.com"
>
> I have no clue what to do.

Have you followed my previous advice of starting with uWSGI quickstart ?

http://projects.unbit.it/uwsgi/wiki/Quickstart

If you are able to follow it, then adding a webserver should be a pretty
easy task (and yesterday, uWSGI got https support so you do not even need
a full webserver for simple deployments)

automagic-script are not the best way to learn. And i really hope you want
to learn, because if you blindly cut&paste you will be in serious trouble
when something will go wrong (and things always go wrong soon or later).

By the way, i am happy you offered help in improving docs, a lot of users
tend to only rant forgetting they are using something for free, and
helping in something "annoying" like writing docs is always appreciated.


--
Roberto De Ioris
http://unbit.it

[Gour]

On Thu, 17 May 2012 06:22:20 +0200
"Roberto De Ioris" <rob...@unbit.it> wrote:

> If you are able to follow it, then adding a webserver should be a
> pretty easy task (and yesterday, uWSGI got https support so you do
> not even need a full webserver for simple deployments)

What is considered 'simple deployment'?

At the moment we use lighttpd for a few small-medium PHP-based sites
which we plan to migrate (with a time) to web2py-based CMS.

Does this scenario count in?


Sincerely,
Gour

--
As the ignorant perform their duties with attachment to results,
the learned may similarly act, but without attachment, for the
sake of leading people on the right path.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Roberto De Ioris]

> On Thu, 17 May 2012 06:22:20 +0200
> "Roberto De Ioris" <rob...@unbit.it> wrote:
>
>> If you are able to follow it, then adding a webserver should be a
>> pretty easy task (and yesterday, uWSGI got https support so you do
>> not even need a full webserver for simple deployments)
>
> What is considered 'simple deployment'?

In my mind, less than 20 concurrent connections :)

For others it is often a matter of money, if i get 10$ for configuring a
webserver would you prefer to setup
lighttpd/nginx/apache/cherokee/mongrel2 + uwsgi/gunicorn/mod_wsgi

or simply do:

uwsgi --https :443,cert.pem,cert.key --wsgi-file web2py/wsgihandler.py
--master --processes 4

obviously if you start needing features, like client certificate
management, ssl caching and so on, the uWSGI https implementation is no
more than a toy.

[Gour]

On Thu, 17 May 2012 07:27:53 +0200
"Roberto De Ioris" <rob...@unbit.it> wrote:

> In my mind, less than 20 concurrent connections :)

Good. I'm in. ;)

> For others it is often a matter of money, if i get 10$ for
> configuring a webserver would you prefer to setup
> lighttpd/nginx/apache/cherokee/mongrel2 + uwsgi/gunicorn/mod_wsgi
>
> or simply do:
>
> uwsgi --https :443,cert.pem,cert.key --wsgi-file web2py/wsgihandler.py
> --master --processes 4

Fair enough.

> obviously if you start needing features, like client certificate
> management, ssl caching and so on, the uWSGI https implementation is
> no more than a toy.

Probably good-enough for our anticipated setup.


Sincerely,
Gour

--
Never was there a time when I did not exist,
nor you, nor all these kings; nor in the future
shall any of us cease to be.

[pbreit]

Is it conceivable that a uwsgi + nginx bundle could be produced making python deployment super easy?

[Massimo Di Pierro]

You mean like a virtual machine? or an installation script?

[Marco Tulio Cicero de M. Porto]

Hi!

Not sure if it's your case.
I had a similar problem, asked around and Bruce Wade told me that there were a few changes on uwsgi on ubuntu, so he changed the installation script a bit and posted it on the list.

The link is:

https://groups.google.com/forum/#!searchin/web2py/nginx$20update/web2py/ysmeR0mZVZo/nOBTKhPOgi8J

Worked for me.
Hope it works for you too.

Cheers,
Marco Tulio

2012/5/16 Lewis <lewis...@hotmail.com>

--
[]'s
Marco Tulio

[Lewis]

Saw the slice from Bruce.  I was already there.

I have spent some 14 hours on this.  I have read the docs on many of the uwsgi options.  I have looked more carefully at the nginx docs.  I now get some diagnostics that tell me much more about what is going on.  Along the way I have learned to hand-author init scripts (somewhat).

Here is what I found out and have done.

1. I believe that cherokee may have installed uwsgi itself or maybe not.  But, I believe I had more than one version of uwsgi installed and criss-crossing symlinks.  Plus, the version that apt-get retrieves for ubuntu 11.10 is ancient.

2. I completed removed old installs of uwsgi.

3. I installed uwsgi 1.2.3 directly from unbit.it using pip. Unfortunately, this only builds the binary.  You get no config and no init script.  But, you do get a clean up-to-date binary.  That is something.

4. Looking at a clean nginx init and several examples of uwsgi init's, I created one.  It evolved and I believe it works. 

5. I created a more complete web2py.xml file for uwsgi.  There is a lot of conflicting information flloating around about this that is quite out of date (Bruce Wade got a bit of it more up to date).

6. I cleaned up my nginx and made sure it served static files so at least I could be sure that nginx was basically working before I changed the virtual server definitions to enable uwsgi and web2py.  (It did indeed serve "hello, world!")

But, I still don't think I am that much closer to having this work.  I no longer get 502 bad gateway. I get 504 gateway timeout.

Here is my uwsgi log:

*** Starting uWSGI 1.2.3 (32bit) on [Fri May 18 09:27:27 2012] ***
compiled with version: 4.6.1 on 17 May 2012 23:33:21
detected number of CPU cores: 4
current working directory: /
writing pidfile to /var/run/uwsgi.pid
detected binary path: /usr/local/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
setgid() to 33
setuid() to 33
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to TCP address 127.0.0.1:9001 fd 3
Python version: 2.7.2+ (default, Oct  4 2011, 20:29:37)  [GCC 4.6.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x9829bd8
your server socket listen backlog is limited to 100 connections
*** Operational MODE: no-workers ***
added /var/web2py/ to pythonpath.
mounting /var/web2py/wsgihandler.py on /
WSGI app 0 (mountpoint='/') ready in 0 seconds on interpreter 0x9829bd8 pid: 25731 (default app)
spawned uWSGI master process (pid: 25731)

The fact that there are no workers is obviously wrong.  I requested 4 processes.   I sort of wonder about the working directory.  But, I am launching uwsgi and python and pointing to wsgihandler.py.

Here is the web2py.xml.  It looks A LOT different from anything in the cookbook or slices:

<uwsgi>
    <uid>33</uid>
    <gid>33</gid>
    <pidfile>/var/run/uwsgi.pid</pidfile>
    <pythonpath>/var/web2py/</pythonpath>
    <daemonize>/var/log/uwsgi.log</daemonize>
<socket>127.0.0.1:9001</socket>
    <processes>4</processes>
    <master/>
    <mount>/=/var/web2py/wsgihandler.py</mount>
    <memory-report/>
</uwsgi>

Here is the config for nginx (please ignore the port 443 setup--I just wanted to win one battle before moving on...):

server {
listen 80;
server_name $hostname;
location ~* /(\w+)/static/ {
            root /var/web2py/applications/;
            }
    location / {
        uwsgi_pass          127.0.0.1:9001;
        include             uwsgi_params;
        }
    }
server {
listen 443;
server_name $hostname;
ssl on;
ssl_certificate /etc/nginx/ssl/web2py.crt;
ssl_certificate_key /etc/nginx/ssl/web2py.key;
}

 

One more suspicious symptom is that when I look at running processes, I only see the one master for uwsgi:

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Mar05 ?        00:00:09 /sbin/init
root         2     0  0 Mar05 ?        00:00:00 [kthreadd]
root         3     2  0 Mar05 ?        00:00:32 [ksoftirqd/0]
root         5     2  0 Mar05 ?        00:00:00 [kworker/u:0]
root         6     2  0 Mar05 ?        00:00:00 [migration/0]
root         7     2  0 Mar05 ?        00:00:00 [migration/1]
root         8     2  0 Mar05 ?        00:00:00 [kworker/1:0]
root         9     2  0 Mar05 ?        00:00:40 [ksoftirqd/1]
root        10     2  0 Mar05 ?        00:00:00 [migration/2]
root        11     2  0 Mar05 ?        00:00:00 [kworker/2:0]
root        12     2  0 Mar05 ?        00:00:31 [ksoftirqd/2]
root        13     2  0 Mar05 ?        00:00:00 [migration/3]
root        14     2  0 Mar05 ?        00:00:00 [kworker/3:0]
root        15     2  0 Mar05 ?        00:00:40 [ksoftirqd/3]
root        16     2  0 Mar05 ?        00:00:00 [cpuset]
root        17     2  0 Mar05 ?        00:00:00 [khelper]
root        18     2  0 Mar05 ?        00:00:00 [kworker/u:1]
root        22     2  0 Mar05 ?        00:00:00 [xenwatch]
root        23     2  0 Mar05 ?        00:00:00 [xenbus]
root       149     2  0 Mar05 ?        00:00:18 [sync_supers]
root       151     2  0 Mar05 ?        00:00:00 [bdi-default]
root       153     2  0 Mar05 ?        00:00:00 [kblockd]
root       163     2  0 Mar05 ?        00:00:00 [md]
root       247     2  0 Mar05 ?        00:00:00 [rpciod]
root       248     2  0 Mar05 ?        00:02:37 [kworker/2:1]
root       280     2  0 Mar05 ?        00:00:01 [kswapd0]
root       281     2  0 Mar05 ?        00:00:00 [ksmd]
root       282     2  0 Mar05 ?        00:00:00 [fsnotify_mark]
root       286     2  0 Mar05 ?        00:00:00 [ecryptfs-kthrea]
root       288     2  0 Mar05 ?        00:00:00 [nfsiod]
root       291     2  0 Mar05 ?        00:00:00 [jfsIO]
root       292     2  0 Mar05 ?        00:00:00 [jfsCommit]
root       293     2  0 Mar05 ?        00:00:00 [jfsCommit]
root       294     2  0 Mar05 ?        00:00:00 [jfsCommit]
root       295     2  0 Mar05 ?        00:00:00 [jfsCommit]
root       296     2  0 Mar05 ?        00:00:00 [jfsSync]
root       297     2  0 Mar05 ?        00:00:00 [xfs_mru_cache]
root       298     2  0 Mar05 ?        00:00:00 [xfslogd]
root       299     2  0 Mar05 ?        00:00:00 [xfsdatad]
root       300     2  0 Mar05 ?        00:00:00 [xfsconvertd]
root       301     2  0 Mar05 ?        00:00:00 [glock_workqueue]
root       302     2  0 Mar05 ?        00:00:00 [delete_workqueu]
root       303     2  0 Mar05 ?        00:00:00 [gfs_recovery]
root       304     2  0 Mar05 ?        00:00:00 [crypto]
root       866     2  0 Mar05 ?        00:00:00 [khvcd]
root       968     2  0 Mar05 ?        00:01:43 [kworker/0:1]
root       981     2  0 Mar05 ?        00:00:00 [kpsmoused]
root       982     2  0 Mar05 ?        00:05:35 [kworker/1:1]
root      1009     2  0 Mar05 ?        00:01:37 [kjournald]
root      1038     1  0 Mar05 ?        00:00:00 upstart-udev-bridge --daemon
root      1913     2  0 Mar05 ?        00:03:32 [kworker/3:1]
root      1933     1  0 Mar05 ?        00:00:00 upstart-socket-bridge --daemon
root      1974     1  0 Mar05 ?        00:00:00 dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases -1 eth0
root      1995     1  0 Mar05 ?        00:01:25 /usr/sbin/sshd -D
syslog    2029     1  0 Mar05 ?        00:10:58 rsyslogd -c5
102       2032     1  0 Mar05 ?        00:00:00 dbus-daemon --system --fork --activation=upstart
daemon    2079     1  0 Mar05 ?        00:00:00 atd
root      2080     1  0 Mar05 ?        00:00:11 cron
root      2201     2  0 Mar05 ?        00:00:39 [flush-202:0]
root      2268     1  0 Mar05 hvc0     00:00:00 /sbin/getty -8 38400 hvc0
ntp       2318     1  0 Mar05 ?        00:06:18 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 105:110
root     17087     2  0 Apr07 ?        00:00:54 [kworker/0:2]
root     22656  1995  0 05:11 ?        00:00:01 sshd: root@pts/0    
root     22671 22656  0 05:11 pts/0    00:00:00 -bash
root     23855  1995  0 06:55 ?        00:00:00 sshd: root@notty    
root     23870 23855  0 06:55 ?        00:00:00 /usr/lib/openssh/sftp-server
www-data 25731     1  0 09:27 ?        00:00:00 /usr/local/bin/uwsgi -x /etc/uwsgi/uwsgi-conf.xml -p /var/run/uwsgi.pid
root     25752     1  0 09:28 ?        00:00:00 nginx: master process /usr/sbin/nginx
www-data 25753 25752  0 09:28 ?        00:00:00 nginx: worker process
www-data 25754 25752  0 09:28 ?        00:00:00 nginx: worker process
www-data 25755 25752  0 09:28 ?        00:00:00 nginx: worker process
www-data 25756 25752  0 09:28 ?        00:00:00 nginx: worker process
root     26018 22671  0 09:59 pts/0    00:00:00 ps -ef
postgres 29498     1  0 May16 ?        00:00:18 /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf
postgres 29500 29498  0 May16 ?        00:00:19 postgres: writer process                                                                                                    
postgres 29501 29498  0 May16 ?        00:00:18 postgres: wal writer process                                                                                                
postgres 29502 29498  0 May16 ?        00:00:15 postgres: autovacuum launcher process                                                                                       
postgres 29503 29498  0 May16 ?        00:00:26 postgres: stats collector process                                                                                           
mysql    29796     1  0 May16 ?        00:00:25 /usr/sbin/mysqld
root     29855     1  0 May16 ?        00:00:00 udevd --daemon

That's the news from Lake Woebegone.  

On the surface, nginx looks much easier to set up than apache.  But, uwsgi seems much more difficult than mod_wsgi.

Thanks for everyone's help.

[Roberto De Ioris]

Il giorno 18/mag/2012, alle ore 12:05, Lewis ha scritto:

>
>
>
> That's the news from Lake Woebegone.
>
> On the surface, nginx looks much easier to set up than apache. But, uwsgi seems much more difficult than mod_wsgi.
>
> Thanks for everyone's help.
>

From your latest config i have to assume you have finally followed my advice on reading the Quickstart.
Finally your config does not look a copy&paste :) I would make it even simpler, but for now is enough.

By the way, do not you think ps aux has helped you showing the problem ?

/usr/local/bin/uwsgi -x /etc/uwsgi/uwsgi-conf.xml -p /var/run/uwsgi.pid

why that -p ?

from the --help:

-p|--processes <n> spawn <n> uwsgi worker processes
-p|--workers <n> spawn <n> uwsgi worker processes

So:

/usr/local/bin/uwsgi -x /etc/uwsgi/uwsgi-conf.xml

should do the trick.

After that (i suppose it will start working). Re-read your config, check official docs, and tell me if you really think all of this stuff does not make sense or
is over-hard ;) You simply pointed your eyes to the wrong places (and that is a common problem, do not worry) and you have been beaten by some "funny"
distro choice.

--
Roberto De Ioris
http://unbit.it

JID: rob...@jabber.unbit.it

[Lewis]

What you've sent is incomprehensible (not because of IT to EN--the language is fine).

Command line arguments in the init script did not work because they go through start-stop-daemon .  I moved most things to the xml.  The remaining argument that goes directly to uwsgi is: -x /etc/uwsgi/uwsgi-conf.xml.  This seems to be what you are recommending.  It is in place via the init script.

[Lewis]

Ran that command line.  Doesn't work.

Instead of command line arg for processes, I put it in xml. does it matter?

[Roberto De Ioris]

Il giorno 18/mag/2012, alle ore 12:42, Lewis ha scritto:

> Ran that command line. Doesn't work.
>
> Instead of command line arg for processes, I put it in xml. does it matter?

You mean running "ps aux" now shows

/usr/local/bin/uwsgi -x /etc/uwsgi/uwsgi-conf.xml

instead of the (wrong)

/usr/local/bin/uwsgi -x /etc/uwsgi/uwsgi-conf.xml -p /var/run/uwsgi.pid

? (the second is wrong because -p takes a number, and in addition to that you have already specified the number of processes inthe xml file, so no need to
double-use it)

By the way try to follow that steps (run a ps aux after each step to be sue all is fine):

1) stop all (nginx, uwsgi)
2) run only nginx
3) from your terminal run (this is the minimal config for web2py)

sudo /usr/local/bin/uwsgi --chdir /var/web2py/ --module wsgihandler --socket 127.0.0.1:9001

(it means: move to /var/web2py/, load wsgihandler module and bind to socket 127.0.0.1:9001)
Now visit your website with your browser. Does it work ?

If it does not work double check if /var/web2py is the correct path of your web2py installation.

[Bruce Wade]

Updates:

1) On production I am not using the XML style configuration file as I was having problems with it. Instead I have set the file /etc/default/uwsgi inside this file you need two lines (you can also place other configuration) PYTHONPATH=path_to_web_2_py_project and MODULE=wsgihandler

/etc/default/uwsgi

-------------------------------

PYTHONPATH=/home/developer/projects/yaw

MODULE=wsgihandler

2) It is important to note which ever user you set uwsgi to start as ALL of your files in your project need to be owned by that user other wise the process will not start. This may be the reason you do not see the uwsgi daemon. 

Try this: 

cd path_of_web2py_project

type: uwsgi  uwsgi --socket 127.0.0.1:3031 -w wsgihandler.py

Also very important make sure you set wsgihandler to be executable as by default is is not.

chmod +x wsgihandler.py

3) Finally look at the nginx error logs I have found that the the uwsgi error logs most of the time don't help however the nginx have provided me with the access denied messages.

nginx:

server {

        listen       80;

        server_name  youadstage youadworld.com;

        access_log /home/developer/projects/logs/access.log main;

        error_log /home/developer/projects/logs/error.log;

        #limit_req   zone=gulag burst=200 nodelay;

        #charset koi8-r;

        rewrite ^(.*) https://new.youadworld.com$1 permanent;

        #access_log  logs/host.access.log  main;

        location /(\w+)/(\w+)/static/ {

            root /home/developer/projects/yaw/applications/;

        }

        location / {

            #root   html;

            #index  index.html index.htm;

            include uwsgi_params;

            uwsgi_pass 127.0.0.1:9001;

        }

}

server {

        listen          443;

        server_name     youadstage youadworld.com;

        ssl             on;

        ssl_certificate /home/developer/projects/yaw/settings/public.crt;

        ssl_certificate_key /home/developer/projects/yaw/settings/youadworld.com.key;

        location / {

            uwsgi_pass  127.0.0.1:9001;

            include     uwsgi_params;

            uwsgi_param UWSGI_SCHEME $scheme;

        }

    }

Hopefully this helps a bit more.

--

Regards,

Bruce

--
--
Regards,
Bruce Wade
http://ca.linkedin.com/in/brucelwade
http://www.wadecybertech.com

http://www.fittraineronline.com - Fitness Personal Trainers Online
http://www.warplydesigned.com

[Jonathan Lundell]

On May 18, 2012, at 3:29 AM, Roberto De Ioris wrote:
>
> From your latest config i have to assume you have finally followed my advice on reading the Quickstart.
> Finally your config does not look a copy&paste :) I would make it even simpler, but for now is enough.

A more general question, for those of us more comfortable on the application side of the fence.

Last week I deployed web2py on a Rackspace managed server (Ubuntu). The server comes up with Apache running, so rather than mess with it I installed mod_wsgi and got on with my life.

My general question: what would my motivation be for migrating to (say) nginx+uwsgi? What is each of them doing for me? Serve more requests with a set of server resources, presumably, but what Apache+mod_wsgi problems are they solving?

[pbreit]

Someone posted this pretty simple script today. Might work on older Ubuntu versions:

https://groups.google.com/forum/#!topic/web2py/moZqFqZ8eHo

Are you on a cloud server that you can rebuild? If so, I'd recommend a rebuild and start from scratch.

If your server comes with Apache pre-installed that's probably a fine way to go. I was not experienced with either Apache or Nginx and found Nginx a *lot* easier to understand. And it seems pretty unanimous that Nginx is more performant across the board.

[Lewis]

Guys, let me say thanks first.

Everything I have was working fine under apache2 and mod_wsgi.  I even had parallel access to php and static files.  I wanted to switch to nginx to make ssl config easier.

could there be any holdover somewhere from the apache/mod_wsgi config?

Because everything once worked I don't think the problem is on the python or web2py side.  (I verified all permissions though...)

The nginx error log shows two kinds of problems (depends on which experiment I was doing with a config):

2012/05/18 10:41:11 [error] 26348#0: *11 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 76.22.75.122, server: lewlin1, request: "GET / HTTP/1.1", upstream: "uwsgi://127.0.0.1:9001", host: "www.lewcl.com"
2012/05/18 17:20:34 [error] 29959#0: *4 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 66.249.68.103, server: lewlin1, request: "GET /robots.txt HTTP/1.1", upstream: "uwsgi://127.0.0.1:9001", host: "lewcl.com"

Bruce:  I don't understand why I should be starting web2py manually.  I never did before on apache/mod_wsgi.  It's wsgi's job to call python and the handler's job to run the right application, as I understand the role of the gateway.

I am going to try the suggestion of running little bits of the stack using command lines with fewer arguments to try to isolate the problem.

[Bruce Wade]

Start it manually was just to test the configuration of uwsgi. If that manual test works then you know the problem isn't with uwsgi.

[Lewis]

Bruce:  do you only need two lines of uwsgi config?  Where do you put the rest of the directives?   command line?

Does anyone know how to have one uwsgi config file load another (as we do in apache)?  I was trying to see an example or find it in uwsgi docs to no avail.

[Roberto De Ioris]

> Bruce: do you only need two lines of uwsgi config? Where do you put the
> rest of the directives? command line?
>
> Does anyone know how to have one uwsgi config file load another (as we do
> in apache)? I was trying to see an example or find it in uwsgi docs to no
> avail.
>
>

http://projects.unbit.it/uwsgi/wiki/ParsingOrder

[Bruce Wade]

That is the only two lines I have nothing set on the command line. uwsgi should by default look into that directory.

Oh yes there is one other thing you need to change in /etc/init.d/uwsgi (if you have this) the path to uwsgi is /usr/local/bin/uwsgi

You also set in that file OWNER NAME DESC

/etc/init.d/uwsgi:

PATH=/opt/uwsgi:/sbin:/bin:/usr/sbin:/usr/bin

DAEMON=/usr/local/bin/uwsgi

OWNER=uwsgi

NAME=uwsgi

DESC=uwsgi

echo "Trying test"

test -x $DAEMON || exit 0

echo "test passed"

# Include uwsgi defaults if available

if [ -f /etc/default/uwsgi ] ; then

        . /etc/default/uwsgi

fi

set -e

# I added --limit-post 4096 to prevent post attacks

DAEMON_OPTS="-s 127.0.0.1:9001 -M 4 -t 30 -A 4 -p 4 -d /var/log/uwsgi.log --pythonpath $PYTHONPATH --module $MODULE --limit-post 4096"

case "$1" in

  start)

        echo -n "Starting $DESC: "

        start-stop-daemon --start --chuid $OWNER:$OWNER --user $OWNER \

                --exec $DAEMON -- $DAEMON_OPTS

        echo "$NAME."

        ;;

  stop)

        echo -n "Stopping $DESC: "

        start-stop-daemon --signal 3 --user $OWNER --quiet --retry 2 --stop \

                --exec $DAEMON

        echo "$NAME."

        ;;

  reload)

        killall -1 $DAEMON

        ;;

  force-reload)

        killall -15 $DAEMON

       ;;

  restart)

        echo -n "Restarting $DESC: "

        start-stop-daemon --signal 3 --user $OWNER --quiet --retry 2 --stop \

                --exec $DAEMON

        sleep 1

        start-stop-daemon --user $OWNER --start --quiet --chuid $OWNER:$OWNER \

               --exec $DAEMON -- $DAEMON_OPTS

        echo "$NAME."

        ;;

  status)

        killall -10 $DAEMON

        ;;

      *)

            N=/etc/init.d/$NAME

            echo "Usage: $N {start|stop|restart|reload|force-reload|status}" >&2

            exit 1

            ;;

    esac

    exit 0

[Lewis]

Success!   --but it's not clear why!?!

I ran uwsgi with the following commmand line (note that I switched to unix sock in my location directive in nginx to match...):

uwsgi -s /tmp/web2py.sock --module wsgihandler --pythonpath /var/web2py --daemonize /var/log/uwsgi.log

This means that there is something funky in either my init script or in my xml:

Bruce: thanks for the init suggestions.  Mine was similar but I did not set OWNER (I would use www-data as I don't have a uwsgi user) and I did not set .e.

Roberto: I'll look at the parsing order link you sent.

Well, now I know it does work and can work with a "known good setting."  After I try to debug the "manly, professional" approach I can always revert to the cmd line or to using ini file approach.

Trial and error is not fun.  I have something that works but I still don't know what was "broke."

Thanks everyone.

I'll do a write up that is more "theory and practice" rather than cookbook.  There are too many variations to rely on anyone else's cookbook unless your own config is nearly identical to one that you try to mimic.

[Lewis]

Well, I revised my init.d script to work.

Config files do not work at all in any way, shape or form.  Just broken utterly.

It turns out even loading simple startup variables to the init script does not work.  Period.

It would appear that for some reason the only way uwsgi works is with command line arguments, many of which aren't documented.  For example, everyone uses -M.  I did a search for it in the wiki.  Many examples include it.  The global listing of (not) all arguments does not show it.  What is it?

I am on a linode vps running ubuntu 11.10.  The only person who logs on is me to do config horrors. I log on as root.  So, the commmand line to start uwsgi is run as root.  As a command line, it works.  When it references any external config file it does not work.  Should I file a ticket, Roberto?  You'll say you can't reproduce.   But, I can't reproduce it ever working at all.   So, I have wasted 20 hours attempting to debug config files that are inherently unusable.

[Roberto De Ioris]

> Well, I revised my init.d script to work.
>
> Config files do not work at all in any way, shape or form. Just broken
> utterly.
>
> It turns out even loading simple startup variables to the init script does
> not work. Period.
>
> It would appear that for some reason the only way uwsgi works is with
> command line arguments, many of which aren't documented. For example,
> everyone uses -M. I did a search for it in the wiki. Many examples
> include it. The global listing of (not) all arguments does not show it.
> What is it?
>
> I am on a linode vps running ubuntu 11.10. The only person who logs on is
> me to do config horrors. I log on as root. So, the commmand line to start
> uwsgi is run as root. As a command line, it works. When it references
> any
> external config file it does not work. Should I file a ticket, Roberto?
> You'll say you can't reproduce. But, I can't reproduce it ever working
> at all. So, I have wasted 20 hours attempting to debug config files that
> are inherently unusable.

Run

uwsgi --help

for the full list of options (and their shortcuts). I suggest you to not
use shortcuts, as you will forget what they mean soon. Use long format.

-M --> --master

Regarding config files, read here how they works:

http://projects.unbit.it/uwsgi/wiki/Doc

(you do not need to read it all, just the first part).

Try that (call it foo.ini)

[uwsgi]
http = :8080
master = true

Then

uwsgi --ini foo.ini

Go to your browser to port 8080, it will work for sure.

I suspect you are trying with xml files, but without xml support.
If you really love xml format, be sure to have installed libxml2-dev as
described here:

http://projects.unbit.it/uwsgi/wiki/Install

and rebuild uWSGI.

Finally, you are on Ubuntu, throw away those ancient init scripts and use
what Ubuntu wants: upstart scripts

http://projects.unbit.it/uwsgi/wiki/Upstart

Obviously the previous link does not show you how upstart works, but you
can find more complete docs on ubuntu site (it is a lot easier than init
scripts and Ubuntu will not move to SystemD, so you'd better to invest a
bit of time in it).

Another important link is that one:

http://projects.unbit.it/uwsgi/wiki/ThingsToKnow

I think you have all the pieces.

[Gour]

On Fri, 18 May 2012 14:53:40 -0700 (PDT)
Lewis <lewis...@hotmail.com> wrote:

> Well, I revised my init.d script to work.
>
> Config files do not work at all in any way, shape or form. Just
> broken utterly.

> It turns out even loading simple startup variables to the init script
> does not work. Period.

[...]

> So, I have wasted 20 hours attempting to debug config files that are
> inherently unusable.

Based on my experience I can say that Cherokee works with uWSGI and I
believe it won't be a problem to make it work with lighttpd, although I
do not have personal experience with nginx.

Moreover, I also did manage to make uWSGI work with --http option.

So, my well-wished suggestion is to start from the simple setup on your
localhost (desktop/netbook/whatever) machine using Linux under VM (e.g.
virtuablbox) if your desktop is non-Linux and make it work there. Then,
knowing what's going on, you can proceed towards your Linode VPS.


Sincerely,
Gour

--
A person is said to be established in self-realization and is called a
yogī [or mystic] when he is fully satisfied by virtue of acquired
knowledge and realization. Such a person is situated in transcendence
and is self-controlled. He sees everything — whether it be pebbles,
stones or gold — as the same.

[Lewis]

Thanks to Bruce Wade who suggested going all command line.  In an init file with an args variable it is no problem to have a very long list of args.

Roberto:  I used pip to install v 1.2.3.  Would it have included xml support by default?  I had previously downloaded the package for xml but perhaps the default build doesn't include it.  I am not in love with xml.  It is what all the cookbooks and nearly every web site showed (for example, most of the django guys write up uwsgi using xml config files).  I'd be perfectly happy with json or ini style config files.  Is support for both "built in?"

I had read the doc on the options but sometimes the short form is not mentioned.  I'd agree that it makes sense to use long form.

In answer to one of your earlier questions--yes, the options and the way uwsgi works is logical.  It is very functional.  The problem comes when some fundamental prereq is left out during the build or install (if retrieving some very out of date version from a repository).  Then, it becomes very difficult to diagnose what is going wrong.  

As (very) frustrating as it was I am happy with the change.   Dozens of lines of apache config are replaced by less than a dozen lines for nginx.

Enough with admin for a while.  Back to design and coding--the fun stuff.

Case closed.

[Deidre]

Can I just say thank you to Gour for his suggestion of setting up a virtual machine and then the same linux as on my VPS. This approach had not occurred to me, but is such a good solution to allowing me to experiment.

Peter

[Gour]

On Sun, 20 May 2012 05:38:35 -0700 (PDT)
Deidre <deid...@googlemail.com> wrote:

> Can I just say thank you to Gour for his suggestion of setting up a
> virtual machine and then the same linux as on my VPS.

I'm glad it was helpful to you. :-)

> This approach had not occurred to me, but is such a good solution to
> allowing me to experiment.

Well, it is always easier to troubleshoot when the environment is (more)
under our control. ;)


Sincerely,
Gour


--
For him who has conquered the mind, the mind is the best of
friends; but for one who has failed to do so, his mind will
remain the greatest enemy.