Sorry for the late reply.
> That's an unmaintained old uwsgi version. Debian jessie shipped with
2.0.7 btw, any chance you can try that? Or a more recent version?
I moved the app out of a VirtualBox container to a physical host which has
another app running (without issues). UWSGI here comes from the unstable
repo:
--------------------------------------------
$ dpkg -l | grep uwsgi
ii uwsgi-core 2.0.12-7
ii uwsgi-plugin-python3 2.0.12-7
$ dpkg -l | grep python3
ii python3 3.5.1-1
--------------------------------------------
The result is the same.
>> I then proceeded to comment everything in the 'script1' except for the
same line as in test - and the result is nothing at all, I don't see the
log line anywhere.
>
> > I can't understand what do you mean with "except for the same line as
in test", how is script1 different than testscript?.
Mistyped 'the same lines'. Let me elaborate a bit: there was a script that
was supposed to be called with subprocess.Popen(). Then for various reasons
I decided to run it as a mule getting messages from the app with
uwsgi.mule_get_msg(), but while I was playing around with it I noticed that
none of the logs it was supposed to be logging were logged. So I then
created a very simple script for testing purposes, here it is:
---------------
#!/usr/bin/python3
from time import sleep
import logging
logging.basicConfig(filename = '/var/log/thisapp/adial.log', level =
logging.DEBUG)
log = logging.getLogger('log')
while True:
log.debug('--> test script: logging')
sleep(5)
------------------
It didn't log to the file however, but to the console where UWSGI was
running. To reproduce at least this behaviour in the original / main script
I've commented out everything but the exact same lines as in the test
script (except for the message to be logged). So now these two scripts are
basically identical. When run as a mule this 'original' script didn't
produce any output, neither in the configured logfile, nor in the shell.
Originally it was run with the following command:
# uwsgi --protocol http --plugins python3 --socket :8080 --mule=mainscript
/srv/www/thisapp/main.py --uid user
After I moved it to the machine with the more recent UWSGI it runs in a
nginx + uwsgi combo, the ini file for the app looks like this:
------------------
$ cat /etc/uwsgi/vassals/thisapp.ini
[uwsgi]
chdir = /srv/www/thisapp
uid = www-data
gid = www-data
protocol = uwsgi
socket = 127.0.0.1:8082
plugins = python3
wsgi-file = main.py
mule = mainscript
mule = testscript
logto = /var/log/uwsgi/%n.log
------------------
I still only see the logs from the testscript...
------------------
binary reloading uWSGI...
chdir() to /etc/uwsgi/vassals
closing all non-uwsgi socket fds > 2 (max_fd = 1024)...
found fd 3 mapped to socket 0 (127.0.0.1:8082)
running /usr/bin/uwsgi-core
*** has_emperor mode detected (fd: 8) ***
[uWSGI] getting INI configuration from autodialer.ini
*** Starting uWSGI 2.0.12-debian (32bit) on [Tue May 17 18:17:29 2016] ***
compiled with version: 5.3.1 20160429 on 08 May 2016 10:46:39
os: Linux-3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
nodename: eris
machine: i686
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/bin/uwsgi-core
chdir() to /srv/www/thisapp
your processes number limit is 64616
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 inherited INET address 127.0.0.1:8082 fd 3
Python version: 3.5.1+ (default, Jan 13 2016, 15:09:18) [GCC 5.3.1
20160101]
*** Python threads support is disabled. You can enable it with
--enable-threads ***
Python main interpreter initialized at 0x8836b00
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 127976 bytes (124 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x8836b00 pid:
2956 (default app)
*** uWSGI is running in multiple interpreter mode ***
gracefully (RE)spawned uWSGI master process (pid: 2956)
spawned uWSGI worker 1 (pid: 8470, cores: 1)
spawned uWSGI mule 1 (pid: 8471)
spawned uWSGI mule 2 (pid: 8472)
DEBUG:log:--> test script: logging
DEBUG:log:--> test script: logging
DEBUG:log:--> test script: logging
...
$ ls -l /srv/www/thisapp
-rwxr-xr-x 1 user www-data 4242 May 17 18:13 mainscript
-rwxr-xr-x 1 user www-data 762 May 17 18:13 testscript
------------------
On Wed, May 11, 2016 at 3:55 PM, Riccardo Magliocchetti <
[email protected]> wrote:
> Il 11/05/2016 11:30, xnrl ha scritto:
>
>> Hello,
>>
>> I've got a bit of a strange problem while trying to utilize a mule.
>>
>> I start uwsgi from shell like this: "uwsgi --protocol http --plugins
>> python3 --socket :8080 --mule=script /srv/www/app/main.py --uid user"
>> At one point I noticed that logging doesn't work - neither to a file nor
>> to stdout; so I created a very simple script to test it:
>>
>> ------------------
>> #!/usr/bin/python3
>>
>> import logging
>>
>> logging.basicConfig(filename = '/var/log/app/app.log', level =
>> logging.DEBUG)
>> log = logging.getLogger('log')
>>
>> log.debug('--> testscript working')
>> ------------------
>>
>> and it sort of worked - only the output appeared not in the file but on
>> stdout.
>>
>
> That's strange
>
> ------------------
>> # uwsgi --protocol http --plugins python3 --socket :8080
>> --mule=testscript /srv/www/app/main.py --uid user
>> [...]
>> spawned uWSGI master process (pid: 25224)
>> spawned uWSGI worker 1 (pid: 25238, cores: 1)
>> spawned uWSGI mule 1 (pid: 25239)
>> DEBUG:log:--> testscript working
>> ------------------
>>
>> I then proceeded to comment everything in the 'script1' except for the
>> same line as in test - and the result is nothing at all, I don't see the
>> log line anywhere.
>>
>
> I can't understand what do you mean with "except for the same line as in
> test", how is script1 different than testscript?.
>
> Permissions on the logfile are 777, owned by the user under whom uwsgi is
>> run (by the --uid option). Both scripts have the same
>> permissions/ownership, reside in the same directory and work as intended
>> when started from shell. I did a diff on both files to determine if the
>> uncommented lines are the same (grepped them with "grep -vE '(^#)|(^\s*$)'
>> script > /tmp/diffX") - they are.
>> Also tried writing something to a file, with and without "if __name__ ==
>> '__main__'" clause - test script works, original doesn't.
>>
>> I can't understand why basically identically scripts work differently, or
>> why the log doesn't go where it should.
>>
>> Do I completely misunderstand how mules are supposed to operate, or is it
>> a simpler problem I'm facing?
>> Using uwsgi 1.2.3+dfsg-5+deb7u1 from repos on debian jessie with python
>> 3.2.3-6
>>
>
> That's an unmaintained old uwsgi version. Debian jessie shipped with 2.0.7
> btw, any chance you can try that? Or a more recent version?
>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.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
