Re: [pylons-discuss] Trying to execute console_scripts in web browser (with nginx and uwsgi)

[Michael Merickel]

Sure I'd at least see if things work fine using waitress to try and confirm
that it's a uwsgi issue. I'm sure uwsgi can be fixed to deal with the
subprocesses better but I do not know how myself.

On Tue, Mar 3, 2020 at 1:39 PM Emerson Barea 
wrote:

> So I'll look for another python server than uwsgi to run my app.
>
> Thank you Michael.
>
>
> Em terça-feira, 3 de março de 2020 15:40:42 UTC-3, Michael Merickel
> escreveu:
>>
>> I suspect it's something to do with UWsgi doing funky things with fork
>> and subprocesses. For example
>> https://stackoverflow.com/questions/17592692/running-a-subprocess-in-uwsgi-application
>> .
>>
>> On Tue, Mar 3, 2020 at 12:37 PM Emerson Barea 
>> wrote:
>>
>>> Hi Michael, thanks for your reply. I'm sorry I didn't confirm it
>>> earlier, but I've been quite sick this past week.
>>>
>>> Well, I tried to follow the suggestion you made, making the following
>>> changes:
>>>
>>> scripts/tests.py
>>>
>>> def main(argv):
>>> 
>>>
>>>
>>> if __name__ == '__main__':
>>> main(argv=sys.argv[1:])
>>>
>>>
>>>
>>> my view code:
>>>
>>> arguments = ['--config_file=minisecbgp.ini',
>>>  '--execution_type=create_node',
>>>  '--hostname=%s' % form.node.data,
>>>  '--username=%s' % form.username.data,
>>>  '--password=%s' % form.password.data]
>>> #subprocess.Popen(['tests'] + arguments)
>>> subprocess.Popen([sys.executable, '-m', 'minisecbgp.scripts.tests'] + 
>>> arguments)
>>>
>>>
>>> and now I receive this erro when I try to execute the view in browser:
>>>
>>> Mar  3 15:24:57 lpttch uwsgi[7284]: /home/tocha/Documentos/projetos/
>>> MiniSecBGP/venv/bin/uwsgi: unrecognized option
>>> '--config_file=minisecbgp.ini'
>>> Mar  3 15:24:57 lpttch uwsgi[7284]: getopt_long() error
>>>
>>> I tried to modify the setyp.py console_scripts to
>>>
>>> 'tests = minisecbgp.scripts.tests'
>>>
>>> or removing this entry_point, since the call to the script is being made
>>> directly now, but I always got the same error.
>>>
>>> Please, do you known what I'm doing wrong?
>>>
>>> Thank you.
>>>
>>> Emerson
>>>
>>>
>>> Em quinta-feira, 27 de fevereiro de 2020 21:28:04 UTC-3, Michael
>>> Merickel escreveu:
>>>
>>>> Your environment isn't modifying the env PATH, which is what Popen is
>>>> relying on to find the script.
>>>>
>>>> It'd be better not rely on the PATH and instead just run the code using
>>>> `python -m foo`, but that doesn't actually work with console scripts. You
>>>> would instead do `subprocess.Popen([sys.executable, '-m',
>>>> 'minisecbgp.scripts.config'] + arguments)`. You'd then need to define an
>>>> `if __name__ == '__main__': main()` in your script instead of relying on
>>>> the console script to invoke your main function.
>>>>
>>>> Alternatively fix your PATH, but I find that less ideal because it can
>>>> change per-environment where the console scripts are actually installed.
>>>>
>>>> - Michael
>>>>
>>>> On Thu, Feb 27, 2020 at 5:41 PM Emerson Barea 
>>>> wrote:
>>>>
>>>>> Hi there.
>>>>>
>>>>> My application has some scripts on .app.scripts (.app.scripts.tests
>>>>> and .app.scripts.config).
>>>>>
>>>>> I configured this scripts in setup.py file like this:
>>>>>
>>>>> entry_points={
>>>>> 'paste.app_factory': [
>>>>> 'main = minisecbgp:main'
>>>>> ],
>>>>> 'console_scripts': [
>>>>> 'initialize_minisecbgp_db = 
>>>>> minisecbgp.scripts.initialize_db:main',
>>>>> 'tests = minisecbgp.scripts.tests:main',
>>>>> 'validate_hostname = minisecbgp.scripts.validate_hostname:main',
>>>>> 'config = minisecbgp.scripts.config:main',
>>>>> ],
>>>>>
>>>>>
>>>>> I call these two scripts in my view with the code below:
>>>>>
>>>>> arguments = ['--config_file=minisecbgp.ini',
>>>>>  '--hostname=%s' % form.node.data,
>>>>>  '--username=%s' % f

Re: [pylons-discuss] Trying to execute console_scripts in web browser (with nginx and uwsgi)

[Emerson Barea]

So I'll look for another python server than uwsgi to run my app.

Thank you Michael.


Em terça-feira, 3 de março de 2020 15:40:42 UTC-3, Michael Merickel 
escreveu:
>
> I suspect it's something to do with UWsgi doing funky things with fork and 
> subprocesses. For example 
> https://stackoverflow.com/questions/17592692/running-a-subprocess-in-uwsgi-application
> .
>
> On Tue, Mar 3, 2020 at 12:37 PM Emerson Barea  > wrote:
>
>> Hi Michael, thanks for your reply. I'm sorry I didn't confirm it earlier, 
>> but I've been quite sick this past week.
>>
>> Well, I tried to follow the suggestion you made, making the following 
>> changes:
>>
>> scripts/tests.py
>>
>> def main(argv):
>> 
>>
>>
>> if __name__ == '__main__':
>> main(argv=sys.argv[1:])
>>
>>
>>
>> my view code:
>>
>> arguments = ['--config_file=minisecbgp.ini',
>>  '--execution_type=create_node',
>>  '--hostname=%s' % form.node.data,
>>  '--username=%s' % form.username.data,
>>  '--password=%s' % form.password.data]
>> #subprocess.Popen(['tests'] + arguments)
>> subprocess.Popen([sys.executable, '-m', 'minisecbgp.scripts.tests'] + 
>> arguments)
>>
>>
>> and now I receive this erro when I try to execute the view in browser:
>>
>> Mar  3 15:24:57 lpttch uwsgi[7284]: /home/tocha/Documentos/projetos/
>> MiniSecBGP/venv/bin/uwsgi: unrecognized option 
>> '--config_file=minisecbgp.ini'
>> Mar  3 15:24:57 lpttch uwsgi[7284]: getopt_long() error
>>
>> I tried to modify the setyp.py console_scripts to 
>>
>> 'tests = minisecbgp.scripts.tests'
>>
>> or removing this entry_point, since the call to the script is being made 
>> directly now, but I always got the same error.
>>
>> Please, do you known what I'm doing wrong?
>>
>> Thank you.
>>
>> Emerson
>>
>>
>> Em quinta-feira, 27 de fevereiro de 2020 21:28:04 UTC-3, Michael Merickel 
>> escreveu:
>>
>>> Your environment isn't modifying the env PATH, which is what Popen is 
>>> relying on to find the script.
>>>
>>> It'd be better not rely on the PATH and instead just run the code using 
>>> `python -m foo`, but that doesn't actually work with console scripts. You 
>>> would instead do `subprocess.Popen([sys.executable, '-m', 
>>> 'minisecbgp.scripts.config'] + arguments)`. You'd then need to define an 
>>> `if __name__ == '__main__': main()` in your script instead of relying on 
>>> the console script to invoke your main function.
>>>
>>> Alternatively fix your PATH, but I find that less ideal because it can 
>>> change per-environment where the console scripts are actually installed.
>>>
>>> - Michael
>>>
>>> On Thu, Feb 27, 2020 at 5:41 PM Emerson Barea  
>>> wrote:
>>>
>>>> Hi there.
>>>>
>>>> My application has some scripts on .app.scripts (.app.scripts.tests and 
>>>> .app.scripts.config).
>>>>
>>>> I configured this scripts in setup.py file like this:
>>>>
>>>> entry_points={
>>>> 'paste.app_factory': [
>>>> 'main = minisecbgp:main'
>>>> ],
>>>> 'console_scripts': [
>>>> 'initialize_minisecbgp_db = minisecbgp.scripts.initialize_db:main',
>>>> 'tests = minisecbgp.scripts.tests:main',
>>>> 'validate_hostname = minisecbgp.scripts.validate_hostname:main',
>>>> 'config = minisecbgp.scripts.config:main',
>>>> ],
>>>>
>>>>
>>>> I call these two scripts in my view with the code below:
>>>>
>>>> arguments = ['--config_file=minisecbgp.ini',
>>>>  '--hostname=%s' % form.node.data,
>>>>  '--username=%s' % form.username.data,
>>>>  '--password=%s' % form.password.data]
>>>> subprocess.Popen(['config'] + arguments)
>>>>
>>>>
>>>> and, when I run my application with the commands  below, everything 
>>>> works well. The page works fine and the scripts tests and config works 
>>>> well.
>>>>
>>>> pip install -e ".[testing]"
>>>> pserve minisecbgp.ini --reload
>>>>
>>>>
>>>> So, I want to put my app in production, and I'm trying to use uwsgi and 
>>>> nginx to do it. When I configured uwsgi and nginx and open th

Re: [pylons-discuss] Trying to execute console_scripts in web browser (with nginx and uwsgi)

[Michael Merickel]

I suspect it's something to do with UWsgi doing funky things with fork and
subprocesses. For example
https://stackoverflow.com/questions/17592692/running-a-subprocess-in-uwsgi-application
.

On Tue, Mar 3, 2020 at 12:37 PM Emerson Barea 
wrote:

> Hi Michael, thanks for your reply. I'm sorry I didn't confirm it earlier,
> but I've been quite sick this past week.
>
> Well, I tried to follow the suggestion you made, making the following
> changes:
>
> scripts/tests.py
>
> def main(argv):
> 
>
>
> if __name__ == '__main__':
> main(argv=sys.argv[1:])
>
>
>
> my view code:
>
> arguments = ['--config_file=minisecbgp.ini',
>  '--execution_type=create_node',
>  '--hostname=%s' % form.node.data,
>  '--username=%s' % form.username.data,
>  '--password=%s' % form.password.data]
> #subprocess.Popen(['tests'] + arguments)
> subprocess.Popen([sys.executable, '-m', 'minisecbgp.scripts.tests'] + 
> arguments)
>
>
> and now I receive this erro when I try to execute the view in browser:
>
> Mar  3 15:24:57 lpttch uwsgi[7284]: /home/tocha/Documentos/projetos/
> MiniSecBGP/venv/bin/uwsgi: unrecognized option
> '--config_file=minisecbgp.ini'
> Mar  3 15:24:57 lpttch uwsgi[7284]: getopt_long() error
>
> I tried to modify the setyp.py console_scripts to
>
> 'tests = minisecbgp.scripts.tests'
>
> or removing this entry_point, since the call to the script is being made
> directly now, but I always got the same error.
>
> Please, do you known what I'm doing wrong?
>
> Thank you.
>
> Emerson
>
>
> Em quinta-feira, 27 de fevereiro de 2020 21:28:04 UTC-3, Michael Merickel
> escreveu:
>
>> Your environment isn't modifying the env PATH, which is what Popen is
>> relying on to find the script.
>>
>> It'd be better not rely on the PATH and instead just run the code using
>> `python -m foo`, but that doesn't actually work with console scripts. You
>> would instead do `subprocess.Popen([sys.executable, '-m',
>> 'minisecbgp.scripts.config'] + arguments)`. You'd then need to define an
>> `if __name__ == '__main__': main()` in your script instead of relying on
>> the console script to invoke your main function.
>>
>> Alternatively fix your PATH, but I find that less ideal because it can
>> change per-environment where the console scripts are actually installed.
>>
>> - Michael
>>
>> On Thu, Feb 27, 2020 at 5:41 PM Emerson Barea 
>> wrote:
>>
>>> Hi there.
>>>
>>> My application has some scripts on .app.scripts (.app.scripts.tests and
>>> .app.scripts.config).
>>>
>>> I configured this scripts in setup.py file like this:
>>>
>>> entry_points={
>>> 'paste.app_factory': [
>>> 'main = minisecbgp:main'
>>> ],
>>> 'console_scripts': [
>>> 'initialize_minisecbgp_db = minisecbgp.scripts.initialize_db:main',
>>> 'tests = minisecbgp.scripts.tests:main',
>>> 'validate_hostname = minisecbgp.scripts.validate_hostname:main',
>>> 'config = minisecbgp.scripts.config:main',
>>> ],
>>>
>>>
>>> I call these two scripts in my view with the code below:
>>>
>>> arguments = ['--config_file=minisecbgp.ini',
>>>  '--hostname=%s' % form.node.data,
>>>  '--username=%s' % form.username.data,
>>>  '--password=%s' % form.password.data]
>>> subprocess.Popen(['config'] + arguments)
>>>
>>>
>>> and, when I run my application with the commands  below, everything
>>> works well. The page works fine and the scripts tests and config works well.
>>>
>>> pip install -e ".[testing]"
>>> pserve minisecbgp.ini --reload
>>>
>>>
>>> So, I want to put my app in production, and I'm trying to use uwsgi and
>>> nginx to do it. When I configured uwsgi and nginx and open the app in
>>> browser, the app works well, but when I call the view that executes the
>>> scripts tests and config, I receave a 502 bad gateway error. Looking at
>>> syslog file, I receaved this error:
>>>
>>> Feb 27 20:12:56 lpttch uwsgi[14110]: subprocess.Popen(['tests'] +
>>> arguments)
>>> Feb 27 20:12:56 lpttch uwsgi[14110]:   File
>>> "/usr/lib/python3.6/subprocess.py", line 729, in __init__
>>> Feb 27 20:12:56 lpttch uwsgi[14110]: restore_signals,
>>> start_new_session)
>>> Feb 27 20:12:56 lpttch uwsgi[14110]:   File
>>> "/usr/lib/python

Re: [pylons-discuss] Trying to execute console_scripts in web browser (with nginx and uwsgi)

[Emerson Barea]

Hi Michael, thanks for your reply. I'm sorry I didn't confirm it earlier, 
but I've been quite sick this past week.

Well, I tried to follow the suggestion you made, making the following 
changes:

scripts/tests.py

def main(argv):



if __name__ == '__main__':
main(argv=sys.argv[1:])



my view code:

arguments = ['--config_file=minisecbgp.ini',
 '--execution_type=create_node',
 '--hostname=%s' % form.node.data,
 '--username=%s' % form.username.data,
 '--password=%s' % form.password.data]
#subprocess.Popen(['tests'] + arguments)
subprocess.Popen([sys.executable, '-m', 'minisecbgp.scripts.tests'] + arguments)


and now I receive this erro when I try to execute the view in browser:

Mar  3 15:24:57 lpttch uwsgi[7284]: /home/tocha/Documentos/projetos/
MiniSecBGP/venv/bin/uwsgi: unrecognized option 
'--config_file=minisecbgp.ini'
Mar  3 15:24:57 lpttch uwsgi[7284]: getopt_long() error

I tried to modify the setyp.py console_scripts to 

'tests = minisecbgp.scripts.tests'

or removing this entry_point, since the call to the script is being made 
directly now, but I always got the same error.

Please, do you known what I'm doing wrong?

Thank you.

Emerson


Em quinta-feira, 27 de fevereiro de 2020 21:28:04 UTC-3, Michael Merickel 
escreveu:

> Your environment isn't modifying the env PATH, which is what Popen is 
> relying on to find the script.
>
> It'd be better not rely on the PATH and instead just run the code using 
> `python -m foo`, but that doesn't actually work with console scripts. You 
> would instead do `subprocess.Popen([sys.executable, '-m', 
> 'minisecbgp.scripts.config'] + arguments)`. You'd then need to define an 
> `if __name__ == '__main__': main()` in your script instead of relying on 
> the console script to invoke your main function.
>
> Alternatively fix your PATH, but I find that less ideal because it can 
> change per-environment where the console scripts are actually installed.
>
> - Michael
>
> On Thu, Feb 27, 2020 at 5:41 PM Emerson Barea  > wrote:
>
>> Hi there.
>>
>> My application has some scripts on .app.scripts (.app.scripts.tests and 
>> .app.scripts.config).
>>
>> I configured this scripts in setup.py file like this:
>>
>> entry_points={
>> 'paste.app_factory': [
>> 'main = minisecbgp:main'
>> ],
>> 'console_scripts': [
>> 'initialize_minisecbgp_db = minisecbgp.scripts.initialize_db:main',
>> 'tests = minisecbgp.scripts.tests:main',
>> 'validate_hostname = minisecbgp.scripts.validate_hostname:main',
>> 'config = minisecbgp.scripts.config:main',
>> ],
>>
>>
>> I call these two scripts in my view with the code below:
>>
>> arguments = ['--config_file=minisecbgp.ini',
>>  '--hostname=%s' % form.node.data,
>>  '--username=%s' % form.username.data,
>>  '--password=%s' % form.password.data]
>> subprocess.Popen(['config'] + arguments)
>>
>>
>> and, when I run my application with the commands  below, everything works 
>> well. The page works fine and the scripts tests and config works well.
>>
>> pip install -e ".[testing]"
>> pserve minisecbgp.ini --reload
>>
>>
>> So, I want to put my app in production, and I'm trying to use uwsgi and 
>> nginx to do it. When I configured uwsgi and nginx and open the app in 
>> browser, the app works well, but when I call the view that executes the 
>> scripts tests and config, I receave a 502 bad gateway error. Looking at 
>> syslog file, I receaved this error:
>>
>> Feb 27 20:12:56 lpttch uwsgi[14110]: subprocess.Popen(['tests'] + 
>> arguments)
>> Feb 27 20:12:56 lpttch uwsgi[14110]:   File 
>> "/usr/lib/python3.6/subprocess.py", line 729, in __init__
>> Feb 27 20:12:56 lpttch uwsgi[14110]: restore_signals, 
>> start_new_session)
>> Feb 27 20:12:56 lpttch uwsgi[14110]:   File 
>> "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
>> Feb 27 20:12:56 lpttch uwsgi[14110]: raise child_exception_type(
>> errno_num, err_msg, err_filename)
>> Feb 27 20:12:56 lpttch uwsgi[14110]: FileNotFoundError: [Errno 2] No 
>> such file or directory: 'tests': 'tests'
>>
>> Please, can somebody help me?
>>
>> Emerson
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to pylons-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://gr

Re: [pylons-discuss] Trying to execute console_scripts in web browser (with nginx and uwsgi)

[Michael Merickel]

Your environment isn't modifying the env PATH, which is what Popen is
relying on to find the script.

It'd be better not rely on the PATH and instead just run the code using
`python -m foo`, but that doesn't actually work with console scripts. You
would instead do `subprocess.Popen([sys.executable, '-m',
'minisecbgp.scripts.config'] + arguments)`. You'd then need to define an
`if __name__ == '__main__': main()` in your script instead of relying on
the console script to invoke your main function.

Alternatively fix your PATH, but I find that less ideal because it can
change per-environment where the console scripts are actually installed.

- Michael

On Thu, Feb 27, 2020 at 5:41 PM Emerson Barea 
wrote:

> Hi there.
>
> My application has some scripts on .app.scripts (.app.scripts.tests and
> .app.scripts.config).
>
> I configured this scripts in setup.py file like this:
>
> entry_points={
> 'paste.app_factory': [
> 'main = minisecbgp:main'
> ],
> 'console_scripts': [
> 'initialize_minisecbgp_db = minisecbgp.scripts.initialize_db:main',
> 'tests = minisecbgp.scripts.tests:main',
> 'validate_hostname = minisecbgp.scripts.validate_hostname:main',
> 'config = minisecbgp.scripts.config:main',
> ],
>
>
> I call these two scripts in my view with the code below:
>
> arguments = ['--config_file=minisecbgp.ini',
>  '--hostname=%s' % form.node.data,
>  '--username=%s' % form.username.data,
>  '--password=%s' % form.password.data]
> subprocess.Popen(['config'] + arguments)
>
>
> and, when I run my application with the commands  below, everything works
> well. The page works fine and the scripts tests and config works well.
>
> pip install -e ".[testing]"
> pserve minisecbgp.ini --reload
>
>
> So, I want to put my app in production, and I'm trying to use uwsgi and
> nginx to do it. When I configured uwsgi and nginx and open the app in
> browser, the app works well, but when I call the view that executes the
> scripts tests and config, I receave a 502 bad gateway error. Looking at
> syslog file, I receaved this error:
>
> Feb 27 20:12:56 lpttch uwsgi[14110]: subprocess.Popen(['tests'] +
> arguments)
> Feb 27 20:12:56 lpttch uwsgi[14110]:   File
> "/usr/lib/python3.6/subprocess.py", line 729, in __init__
> Feb 27 20:12:56 lpttch uwsgi[14110]: restore_signals,
> start_new_session)
> Feb 27 20:12:56 lpttch uwsgi[14110]:   File
> "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
> Feb 27 20:12:56 lpttch uwsgi[14110]: raise child_exception_type(
> errno_num, err_msg, err_filename)
> Feb 27 20:12:56 lpttch uwsgi[14110]: FileNotFoundError: [Errno 2] No such
> file or directory: 'tests': 'tests'
>
> Please, can somebody help me?
>
> Emerson
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/9a78ebba-f50d-4143-9fea-550d3bce9e1e%40googlegroups.com
> <https://groups.google.com/d/msgid/pylons-discuss/9a78ebba-f50d-4143-9fea-550d3bce9e1e%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CAKdhhwFreu9DZgsBA6iwUaPQrHTJvKW_rpNhei9C%3DTApF7ohkg%40mail.gmail.com.

[pylons-discuss] Trying to execute console_scripts in web browser (with nginx and uwsgi)

[Emerson Barea]

Hi there.

My application has some scripts on .app.scripts (.app.scripts.tests and 
.app.scripts.config).

I configured this scripts in setup.py file like this:

entry_points={
'paste.app_factory': [
'main = minisecbgp:main'
],
'console_scripts': [
'initialize_minisecbgp_db = minisecbgp.scripts.initialize_db:main',
'tests = minisecbgp.scripts.tests:main',
'validate_hostname = minisecbgp.scripts.validate_hostname:main',
'config = minisecbgp.scripts.config:main',
],


I call these two scripts in my view with the code below:

arguments = ['--config_file=minisecbgp.ini',
 '--hostname=%s' % form.node.data,
 '--username=%s' % form.username.data,
 '--password=%s' % form.password.data]
subprocess.Popen(['config'] + arguments)


and, when I run my application with the commands  below, everything works 
well. The page works fine and the scripts tests and config works well.

pip install -e ".[testing]"
pserve minisecbgp.ini --reload


So, I want to put my app in production, and I'm trying to use uwsgi and 
nginx to do it. When I configured uwsgi and nginx and open the app in 
browser, the app works well, but when I call the view that executes the 
scripts tests and config, I receave a 502 bad gateway error. Looking at 
syslog file, I receaved this error:

Feb 27 20:12:56 lpttch uwsgi[14110]: subprocess.Popen(['tests'] + 
arguments)
Feb 27 20:12:56 lpttch uwsgi[14110]:   File 
"/usr/lib/python3.6/subprocess.py", line 729, in __init__
Feb 27 20:12:56 lpttch uwsgi[14110]: restore_signals, start_new_session)
Feb 27 20:12:56 lpttch uwsgi[14110]:   File 
"/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
Feb 27 20:12:56 lpttch uwsgi[14110]: raise child_exception_type(
errno_num, err_msg, err_filename)
Feb 27 20:12:56 lpttch uwsgi[14110]: FileNotFoundError: [Errno 2] No such 
file or directory: 'tests': 'tests'

Please, can somebody help me?

Emerson

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/9a78ebba-f50d-4143-9fea-550d3bce9e1e%40googlegroups.com.

[pylons-discuss] uWSGI + Nginx + systemd - new Pyramid Community Cookbook recipe

[Kacper Krupa]

Hey all!

My recipe about setting up uWSGI with Nginx and systemd has been accepted! 
Please find it 
here: 
https://docs.pylonsproject.org/projects/pyramid-cookbook/en/latest/deployment/uwsgi_nginx_systemd.html

Hope it will be helpful for you!

If you have any questions, suggestions feel free to ask.

Thanks,
Kacper.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/925203ca-21a0-456c-bec1-48a515b930df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Getting Nginx + uWSGI + Pyramid working

[Darren Jones]

Hi Steve

I think some of it is Pi (or raspbian) specific, but also I think it's 
something I'd like to do anyway, to provide a guide specific to running it 
on the Pi - could help people who are less experienced get up and running.

When I've got it all up and running nicely (with all the config done in 
files, and it auto-starting on boot, etc), I'm planning to do exactly 
that when!

Darren

On Thursday, 1 March 2018 20:35:42 UTC, Steve Piercy wrote:
>
> Were there any things peculiar to the Raspberry Pi environment 
> to get it running?  If so, it would a cool thing to blog about, 
> or add a recipie to Pyramid Community Cookbook under Deployment. 
>
>
> https://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/deployment/
>  
>
> --steve 
>
>
> On 3/1/18 at 12:10 PM, djay...@gmail.com  (Darren Jones) 
> pronounced: 
>
> >Michael - thanks a million!  That was what I needed (and 
> >another hour of work!) to get it up and running - just got it 
> >running now.  Now that I have it up and running I will be able 
> >to get it all working much more smoothly (I think something is 
> >awry with the current setup and permissions), but I have 
> >something to work from now.  Thanks again, your advice was invaluable! 
> >Darren 
> > 
> >On Thursday, 1 March 2018 19:20:49 UTC, Michael Merickel wrote: 
> >> 
> >>The easiest way to see if your code is installed properly is 
> >>to make sure you are not in the folder with your code and then 
> >>try to import it. 
> >> 
> >>$ cd / 
> >>$ /srv/venv/bin/python 
> >>>>> import gdpr_permissions 
> >> 
> >>If this doesn't work then it's not installed correctly either 
> >>using `/srv/venv/bin/pip install -e 
> >>` or without the `-e` depending 
> >>on your goals. 
> >> 
> >>Further if you want to test that your ini file is pointing at 
> >>your code properly then you can do that similarly. 
> >> 
> >>$ cd / 
> >>$ /srv/venv/bin/python 
> >>>>> from pyramid.paster import get_app 
> >>>>> app = get_app('/srv/myapp/gdpr_permissions/production.ini') 
> >> 
> >>This command is almost exactly what uwsgi is doing to load 
> >>your code and it will fail with the same DistributionNotFound 
> >>error you're seeing. 
> >> 
> >>- Michael 
> >> 
> >> 
> >>On Thu, Mar 1, 2018 at 10:40 AM, Michael Merickel 
> >><mmer...@gmail.com > wrote: 
> >> 
> >>>  The DistributionNotFound error basically always means that 
> >>>your code is  not installed into the virtualenv being used by 
> >>>uwsgi. In this case it's  /srv/venv. You should ensure that 
> >>>you've run /srv/venv/bin/pip install  appropriately. 
> >>> 
> >>> - Michael 
> >>> 
> >>>  On Thu, Mar 1, 2018 at 5:57 AM, Darren Jones 
> >>><djay...@gmail.com  > wrote: 
> >>> 
> >>>> Dear all. 
> >>>> 
> >>>>  I've written my first (worthwhile!) app using Pyramid, and 
> >>>>want to  deploy it to a raspberry pi.  I've got the pi up 
> >>>>and running, and nginx  working fine - it can serve a static 
> >>>>page or even a simple (test, three  line) wsgi app.   
> >>>>However, I am hitting a brick wall on getting the pyramid   
> >>>>app up and running using uWSGI.  I've spent the last three 
> >>>>days (solidly!)  trying to get this up and running, and 
> >>>>still I can't get it going.  I've  tried loads, but my 
> >>>>current issue appears to be that I can't get uWSGI to  run 
> >>>>the pyramid app from the command line - my current launch 
> >>>>command is  sudo uwsgi --plugin python3 -H /srv/venv 
> >>>>production.ini  --socket/srv/myapp/uwsgi.sock 
> >>>> 
> >>>>  When I run this, I just get [uWSGI] getting INI 
> >>>>configuration from  production.ini, and then back to the 
> >>>>command line. 
> >>>> 
> >>>>  Yesterday, I got as far as sudo uwsgi --plugin python3 -H 
> >>>>/srv/venv  --paste 
> >>>>config:/srv/myapp/gdpr_permissions/production.ini --socket   
> >>>>/srv/myapp/uwsgi.sock which was giving me more output (what 
> >>>>looks to be the  uWSGI startup info), but then errors such as 
> >>>> 
> >>>>  pkg_resources.DistributionNotFound: the gdpr_permissions 
> >>>>distribution

Re: [pylons-discuss] Getting Nginx + uWSGI + Pyramid working

[Steve Piercy]

Were there any things peculiar to the Raspberry Pi environment 
to get it running?  If so, it would a cool thing to blog about, 
or add a recipie to Pyramid Community Cookbook under Deployment.


https://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/deployment/

--steve


On 3/1/18 at 12:10 PM, djaych...@gmail.com (Darren Jones) pronounced:

Michael - thanks a million!  That was what I needed (and 
another hour of work!) to get it up and running - just got it 
running now.  Now that I have it up and running I will be able 
to get it all working much more smoothly (I think something is 
awry with the current setup and permissions), but I have 
something to work from now.  Thanks again, your advice was invaluable!

Darren

On Thursday, 1 March 2018 19:20:49 UTC, Michael Merickel wrote:


The easiest way to see if your code is installed properly is 
to make sure you are not in the folder with your code and then 
try to import it.


$ cd /
$ /srv/venv/bin/python

import gdpr_permissions


If this doesn't work then it's not installed correctly either 
using `/srv/venv/bin/pip install -e 
` or without the `-e` depending 
on your goals.


Further if you want to test that your ini file is pointing at 
your code properly then you can do that similarly.


$ cd /
$ /srv/venv/bin/python

from pyramid.paster import get_app
app = get_app('/srv/myapp/gdpr_permissions/production.ini')


This command is almost exactly what uwsgi is doing to load 
your code and it will fail with the same DistributionNotFound 
error you're seeing.


- Michael


On Thu, Mar 1, 2018 at 10:40 AM, Michael Merickel 
<mmer...@gmail.com > wrote:


 The DistributionNotFound error basically always means that 
your code is  not installed into the virtualenv being used by 
uwsgi. In this case it's  /srv/venv. You should ensure that 
you've run /srv/venv/bin/pip install  appropriately.


- Michael

 On Thu, Mar 1, 2018 at 5:57 AM, Darren Jones 
<djay...@gmail.com  > wrote:



Dear all.

 I've written my first (worthwhile!) app using Pyramid, and 
want to  deploy it to a raspberry pi.  I've got the pi up 
and running, and nginx  working fine - it can serve a static 
page or even a simple (test, three  line) wsgi app.  
However, I am hitting a brick wall on getting the pyramid  
app up and running using uWSGI.  I've spent the last three 
days (solidly!)  trying to get this up and running, and 
still I can't get it going.  I've  tried loads, but my 
current issue appears to be that I can't get uWSGI to  run 
the pyramid app from the command line - my current launch 
command is  sudo uwsgi --plugin python3 -H /srv/venv 
production.ini  --socket/srv/myapp/uwsgi.sock


 When I run this, I just get [uWSGI] getting INI 
configuration from  production.ini, and then back to the 
command line.


 Yesterday, I got as far as sudo uwsgi --plugin python3 -H 
/srv/venv  --paste 
config:/srv/myapp/gdpr_permissions/production.ini --socket  
/srv/myapp/uwsgi.sock which was giving me more output (what 
looks to be the  uWSGI startup info), but then errors such as


 pkg_resources.DistributionNotFound: the gdpr_permissions 
distribution  was not found and is required by gdpr_permissions


 I don't seem to be able to find an authoratitive tutorial 
on this - they  either say 'simply enter uWSGI 
production.ini and away you go', or seem to  be 5+ years out 
of date, and I'll get so far and then run aground again -  
many of the links given searching on this list for nginx 
uwsgi lead me to  either dead links, things I've already 
tried, or impenetrably complex  explanations that don't go 
into details relevant to pyramid apps.


 If someone could point me in the right direction, it would 
be immensely  helpful.  I don't -think- I'm a complete idiot 
(I'm happy doing sysadmin  stuff, and have compiled from 
source back in the RH5 days,etc), but it  seems everyone 
else must be able to just get this working without issues  
given the lack of discussion on the subject.  I'm at the 
point of giving up.


Thanks

Darren

 --  You received this message because you are subscribed 
to the Google  Groups "pylons-discuss" group.
 To unsubscribe from this group and stop receiving emails 
from it, send  an email to pylons-discus...@googlegroups.com .
 To post to this group, send email to 
pylons-...@googlegroups.com  .

 To view this discussion on the web visit

https://groups.google.com/d/msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%
40googlegroups.com



<https://groups.google.com/d/msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%
40googlegroups.com?utm_medium=email_source=footer>

.
For more options, visit https://groups.google.com/d/optout.











Steve Piercy, Eugene, OR

--
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss

Re: [pylons-discuss] Getting Nginx + uWSGI + Pyramid working

[Darren Jones]

Michael - thanks a million!  That was what I needed (and another hour of 
work!) to get it up and running - just got it running now.  Now that I have 
it up and running I will be able to get it all working much more smoothly 
(I think something is awry with the current setup and permissions), but I 
have something to work from now.  Thanks again, your advice was 
invaluable!  

Darren

On Thursday, 1 March 2018 19:20:49 UTC, Michael Merickel wrote:
>
> The easiest way to see if your code is installed properly is to make sure 
> you are not in the folder with your code and then try to import it.
>
> $ cd /
> $ /srv/venv/bin/python
> >>> import gdpr_permissions
>
> If this doesn't work then it's not installed correctly either using 
> `/srv/venv/bin/pip install -e ` or without 
> the `-e` depending on your goals.
>
> Further if you want to test that your ini file is pointing at your code 
> properly then you can do that similarly.
>
> $ cd /
> $ /srv/venv/bin/python
> >>> from pyramid.paster import get_app
> >>> app = get_app('/srv/myapp/gdpr_permissions/production.ini')
>
> This command is almost exactly what uwsgi is doing to load your code and 
> it will fail with the same DistributionNotFound error you're seeing.
>
> - Michael
>
>
> On Thu, Mar 1, 2018 at 10:40 AM, Michael Merickel <mmer...@gmail.com 
> > wrote:
>
>> The DistributionNotFound error basically always means that your code is 
>> not installed into the virtualenv being used by uwsgi. In this case it's 
>> /srv/venv. You should ensure that you've run /srv/venv/bin/pip install 
>> appropriately.
>>
>> - Michael
>>
>> On Thu, Mar 1, 2018 at 5:57 AM, Darren Jones <djay...@gmail.com 
>> > wrote:
>>
>>> Dear all.
>>>
>>> I've written my first (worthwhile!) app using Pyramid, and want to 
>>> deploy it to a raspberry pi.  I've got the pi up and running, and nginx 
>>> working fine - it can serve a static page or even a simple (test, three 
>>> line) wsgi app.  However, I am hitting a brick wall on getting the pyramid 
>>> app up and running using uWSGI.  I've spent the last three days (solidly!) 
>>> trying to get this up and running, and still I can't get it going.  I've 
>>> tried loads, but my current issue appears to be that I can't get uWSGI to 
>>> run the pyramid app from the command line - my current launch command is 
>>> sudo uwsgi --plugin python3 -H /srv/venv production.ini 
>>> --socket/srv/myapp/uwsgi.sock
>>>
>>> When I run this, I just get [uWSGI] getting INI configuration from 
>>> production.ini, and then back to the command line.
>>>
>>> Yesterday, I got as far as sudo uwsgi --plugin python3 -H /srv/venv 
>>> --paste config:/srv/myapp/gdpr_permissions/production.ini --socket 
>>> /srv/myapp/uwsgi.sock which was giving me more output (what looks to be the 
>>> uWSGI startup info), but then errors such as
>>>
>>> pkg_resources.DistributionNotFound: the gdpr_permissions distribution 
>>> was not found and is required by gdpr_permissions
>>>
>>> I don't seem to be able to find an authoratitive tutorial on this - they 
>>> either say 'simply enter uWSGI production.ini and away you go', or seem to 
>>> be 5+ years out of date, and I'll get so far and then run aground again - 
>>> many of the links given searching on this list for nginx uwsgi lead me to 
>>> either dead links, things I've already tried, or impenetrably complex 
>>> explanations that don't go into details relevant to pyramid apps.
>>>
>>> If someone could point me in the right direction, it would be immensely 
>>> helpful.  I don't -think- I'm a complete idiot (I'm happy doing sysadmin 
>>> stuff, and have compiled from source back in the RH5 days,etc), but it 
>>> seems everyone else must be able to just get this working without issues 
>>> given the lack of discussion on the subject.  I'm at the point of giving up.
>>>
>>> Thanks
>>>
>>> Darren
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "pylons-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to pylons-discus...@googlegroups.com .
>>> To post to this group, send email to pylons-...@googlegroups.com 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%40googlegroups.com
>>>  

Re: [pylons-discuss] Getting Nginx + uWSGI + Pyramid working

[Michael Merickel]

The easiest way to see if your code is installed properly is to make sure
you are not in the folder with your code and then try to import it.

$ cd /
$ /srv/venv/bin/python
>>> import gdpr_permissions

If this doesn't work then it's not installed correctly either using
`/srv/venv/bin/pip install -e ` or without
the `-e` depending on your goals.

Further if you want to test that your ini file is pointing at your code
properly then you can do that similarly.

$ cd /
$ /srv/venv/bin/python
>>> from pyramid.paster import get_app
>>> app = get_app('/srv/myapp/gdpr_permissions/production.ini')

This command is almost exactly what uwsgi is doing to load your code and it
will fail with the same DistributionNotFound error you're seeing.

- Michael


On Thu, Mar 1, 2018 at 10:40 AM, Michael Merickel <mmeri...@gmail.com>
wrote:

> The DistributionNotFound error basically always means that your code is
> not installed into the virtualenv being used by uwsgi. In this case it's
> /srv/venv. You should ensure that you've run /srv/venv/bin/pip install
> appropriately.
>
> - Michael
>
> On Thu, Mar 1, 2018 at 5:57 AM, Darren Jones <djaych...@gmail.com> wrote:
>
>> Dear all.
>>
>> I've written my first (worthwhile!) app using Pyramid, and want to deploy
>> it to a raspberry pi.  I've got the pi up and running, and nginx working
>> fine - it can serve a static page or even a simple (test, three line) wsgi
>> app.  However, I am hitting a brick wall on getting the pyramid app up and
>> running using uWSGI.  I've spent the last three days (solidly!) trying to
>> get this up and running, and still I can't get it going.  I've tried loads,
>> but my current issue appears to be that I can't get uWSGI to run the
>> pyramid app from the command line - my current launch command is sudo uwsgi
>> --plugin python3 -H /srv/venv production.ini --socket/srv/myapp/uwsgi.sock
>>
>> When I run this, I just get [uWSGI] getting INI configuration from
>> production.ini, and then back to the command line.
>>
>> Yesterday, I got as far as sudo uwsgi --plugin python3 -H /srv/venv
>> --paste config:/srv/myapp/gdpr_permissions/production.ini --socket
>> /srv/myapp/uwsgi.sock which was giving me more output (what looks to be the
>> uWSGI startup info), but then errors such as
>>
>> pkg_resources.DistributionNotFound: the gdpr_permissions distribution
>> was not found and is required by gdpr_permissions
>>
>> I don't seem to be able to find an authoratitive tutorial on this - they
>> either say 'simply enter uWSGI production.ini and away you go', or seem to
>> be 5+ years out of date, and I'll get so far and then run aground again -
>> many of the links given searching on this list for nginx uwsgi lead me to
>> either dead links, things I've already tried, or impenetrably complex
>> explanations that don't go into details relevant to pyramid apps.
>>
>> If someone could point me in the right direction, it would be immensely
>> helpful.  I don't -think- I'm a complete idiot (I'm happy doing sysadmin
>> stuff, and have compiled from source back in the RH5 days,etc), but it
>> seems everyone else must be able to just get this working without issues
>> given the lack of discussion on the subject.  I'm at the point of giving up.
>>
>> Thanks
>>
>> Darren
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pylons-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%40go
>> oglegroups.com
>> <https://groups.google.com/d/msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CAKdhhwE%2BMof%2Bv-tbJy9WO4K-OsyHC-u%2B_aCkCDzmmwMjg_ON_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Getting Nginx + uWSGI + Pyramid working

[Michael Merickel]

The DistributionNotFound error basically always means that your code is not
installed into the virtualenv being used by uwsgi. In this case it's
/srv/venv. You should ensure that you've run /srv/venv/bin/pip install
appropriately.

- Michael

On Thu, Mar 1, 2018 at 5:57 AM, Darren Jones <djaych...@gmail.com> wrote:

> Dear all.
>
> I've written my first (worthwhile!) app using Pyramid, and want to deploy
> it to a raspberry pi.  I've got the pi up and running, and nginx working
> fine - it can serve a static page or even a simple (test, three line) wsgi
> app.  However, I am hitting a brick wall on getting the pyramid app up and
> running using uWSGI.  I've spent the last three days (solidly!) trying to
> get this up and running, and still I can't get it going.  I've tried loads,
> but my current issue appears to be that I can't get uWSGI to run the
> pyramid app from the command line - my current launch command is sudo uwsgi
> --plugin python3 -H /srv/venv production.ini --socket/srv/myapp/uwsgi.sock
>
> When I run this, I just get [uWSGI] getting INI configuration from
> production.ini, and then back to the command line.
>
> Yesterday, I got as far as sudo uwsgi --plugin python3 -H /srv/venv
> --paste config:/srv/myapp/gdpr_permissions/production.ini --socket
> /srv/myapp/uwsgi.sock which was giving me more output (what looks to be the
> uWSGI startup info), but then errors such as
>
> pkg_resources.DistributionNotFound: the gdpr_permissions distribution was
> not found and is required by gdpr_permissions
>
> I don't seem to be able to find an authoratitive tutorial on this - they
> either say 'simply enter uWSGI production.ini and away you go', or seem to
> be 5+ years out of date, and I'll get so far and then run aground again -
> many of the links given searching on this list for nginx uwsgi lead me to
> either dead links, things I've already tried, or impenetrably complex
> explanations that don't go into details relevant to pyramid apps.
>
> If someone could point me in the right direction, it would be immensely
> helpful.  I don't -think- I'm a complete idiot (I'm happy doing sysadmin
> stuff, and have compiled from source back in the RH5 days,etc), but it
> seems everyone else must be able to just get this working without issues
> given the lack of discussion on the subject.  I'm at the point of giving up.
>
> Thanks
>
> Darren
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CAKdhhwH%2BkA1Qged-Cbo5qXNW0k5QPDtCauekc3TztNN_6gMWvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Getting Nginx + uWSGI + Pyramid working

[Darren Jones]

Dear all.

I've written my first (worthwhile!) app using Pyramid, and want to deploy 
it to a raspberry pi.  I've got the pi up and running, and nginx working 
fine - it can serve a static page or even a simple (test, three line) wsgi 
app.  However, I am hitting a brick wall on getting the pyramid app up and 
running using uWSGI.  I've spent the last three days (solidly!) trying to 
get this up and running, and still I can't get it going.  I've tried loads, 
but my current issue appears to be that I can't get uWSGI to run the 
pyramid app from the command line - my current launch command is sudo uwsgi 
--plugin python3 -H /srv/venv production.ini --socket/srv/myapp/uwsgi.sock

When I run this, I just get [uWSGI] getting INI configuration from 
production.ini, and then back to the command line.

Yesterday, I got as far as sudo uwsgi --plugin python3 -H /srv/venv --paste 
config:/srv/myapp/gdpr_permissions/production.ini --socket 
/srv/myapp/uwsgi.sock which was giving me more output (what looks to be the 
uWSGI startup info), but then errors such as

pkg_resources.DistributionNotFound: the gdpr_permissions distribution was 
not found and is required by gdpr_permissions

I don't seem to be able to find an authoratitive tutorial on this - they 
either say 'simply enter uWSGI production.ini and away you go', or seem to 
be 5+ years out of date, and I'll get so far and then run aground again - 
many of the links given searching on this list for nginx uwsgi lead me to 
either dead links, things I've already tried, or impenetrably complex 
explanations that don't go into details relevant to pyramid apps.

If someone could point me in the right direction, it would be immensely 
helpful.  I don't -think- I'm a complete idiot (I'm happy doing sysadmin 
stuff, and have compiled from source back in the RH5 days,etc), but it 
seems everyone else must be able to just get this working without issues 
given the lack of discussion on the subject.  I'm at the point of giving up.

Thanks

Darren

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/6e882888-2ab4-42d7-8502-6c89423104cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Jonathan Vanasco]

On Friday, January 20, 2017 at 12:13:07 PM UTC-5, Zsolt Ero wrote:
>
> I was thinking of that as well, but it implies using the same ini file, 
> which I'd like to keep separate.
>

yes, i believe it does.

i set all my uwgsi options via commandline flags, so ini-paste-logged works 
for me.

it might sound counterproductive, but i use supervisorctl to manage the 
process -- so instead of having different uwsgi configuration files for 
variations on deployment, I have different config files for supervisor.

 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/c7161a56-eef4-4414-a0f0-f1f5cf6dcdf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Zsolt Ero]

I was thinking of that as well, but it implies using the same ini file,
which I'd like to keep separate.


On 2017. Jan 20., Fri at 17:56, Jonathan Vanasco <jvana...@gmail.com> wrote:

> I think the command you want in uwsgi is `ini-paste-logged` instead of
> `paste`
>
>
> http://uwsgi-docs.readthedocs.io/en/latest/Options.html?highlight=paste-logger#ini-paste-logged
>
>
>
>
>
>
>
>
>
>
> --
>
>
> You received this message because you are subscribed to a topic in the
> Google Groups "pylons-discuss" group.
>
>
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pylons-discuss/CO5z2MD3iA0/unsubscribe.
>
>
> To unsubscribe from this group and all its topics, send an email to
> pylons-discuss+unsubscr...@googlegroups.com.
>
>
> To post to this group, send email to pylons-discuss@googlegroups.com.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/d3e7d2b8-84a1-436c-aa5f-6b245afda5f7%40googlegroups.com
> <https://groups.google.com/d/msgid/pylons-discuss/d3e7d2b8-84a1-436c-aa5f-6b245afda5f7%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CAKw-smDuUigFE37DvXCD%2BM0GPWt6MaFqKB4Wx7QTrDWYC-uYTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Jonathan Vanasco]

I think the command you want in uwsgi is `ini-paste-logged` instead of 
`paste`

http://uwsgi-docs.readthedocs.io/en/latest/Options.html?highlight=paste-logger#ini-paste-logged


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/d3e7d2b8-84a1-436c-aa5f-6b245afda5f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Zsolt Ero]

Thanks! So I added "paste-logger = true" and then I got a warning saying:

ImportError: No module named script.util.logging_config

Which I found out on SO can be fixed by installing pastescript. So the
combination of paste-logger = true + pastescript in requirements seems
to have fixed it!

On 19 January 2017 at 18:42, Bert JW Regeer <xiste...@0x58.com> wrote:
> You’ll need something like:
>
> paste-logger = %p
>
> As well for uWSGI to automatically pick up your logger configuration from
> .ini file:
> http://uwsgi-docs.readthedocs.io/en/latest/Options.html?highlight=paste-logger#paste-logger
>
> uWSGI doesn’t automatically pick up your fileConfig logging otherwise.
>
> (Basically unless you explicitly call fileConfig for your .ini right now
> uWSGI doesn’t do anything with your logging handlers/information)
>
>
> On Jan 19, 2017, at 10:17, Zsolt Ero <zsolt@gmail.com> wrote:
>
> I'm just simply calling uwsgi uwsgi.ini and and it has the logto line in
> there.
>
> On 19 January 2017 at 18:16, Bert JW Regeer <xiste...@0x58.com> wrote:
>
> Are you setting up logging explicitly?
>
> uWSGI doesn’t automatically set up Python logging when you provide it a
> paster ini file, how are you starting uWSGI?
>
> Bert
>
> On Jan 19, 2017, at 08:08, Zsolt Ero <zsolt@gmail.com> wrote:
>
> I believe this is uWSGI specific, and might even be a bug in uWSGI, but
> since many people are using uWSGI with Pyramid here, I'd be interested to
> know how did you solve it.
>
>
> I've migrated a project from Gunicorn to uWSGI. My problem is that my
> previously set-up file-based logging is all bypassed / redirected now with
> custom format discarded.
>
>
> Previously it wrote to pyramid.log (and any other specific logs I had). Now,
> after converting to uWSGI:
>
> pyramid.log file is created but empty
> every log is redirected to uwsgi.log, with all custom formatters discarded.
>
> How can I make uWSGI not overwrite the whole, carefully set-up Python
> logging system, and only output it's own log to uwsgi.log?
>
>
> my uwsgi.ini:
>
> [uwsgi]
> paste = config:/home/app/web/app_web/production.ini
> http-socket = :5000
> uid = app
> gid = app
>
> master = true
> processes = 16
> enable-threads = true
> harakiri = 60
> harakiri-verbose = true
> single-interpreter = true
>
> die-on-term = true
> vacuum = true
>
> disable-logging = true
> logto2 = /shared/logs/CURRENT/app/uwsgi.log
>
> stats = /home/app/uwsgi_stats.socket
>
>
> My logging setup is as follows:
>
> [loggers]
> keys = root, app_web, sqlalchemy
>
> [handlers]
> keys = filelog_pyramid
>
> [formatters]
> keys = generic
>
> [logger_root]
> level = WARN
> handlers = filelog_pyramid
>
> [logger_app_web]
> level = WARN
> handlers =
> qualname = app_web
>
> [logger_sqlalchemy]
> level = WARN
> handlers =
> qualname = sqlalchemy.engine
>
> [handler_filelog_pyramid]
> class = FileHandler
> args = ('/shared/logs/CURRENT/app/pyramid.log','a')
> level = NOTSET
> formatter = generic
>
> [formatter_generic]
> format = %(asctime)s %(levelname)-5.5s [%(name)s] %(message)s
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/6c07825a-34f5-4542-b4c2-bf7759eda509%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "pylons-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pylons-discuss/CO5z2MD3iA0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/8DBCF3A1-E4AF-44A2-AD98-0E7A5381DC16%400x58.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@g

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Bert JW Regeer]

You’ll need something like:

paste-logger = %p
As well for uWSGI to automatically pick up your logger configuration from .ini 
file: 
http://uwsgi-docs.readthedocs.io/en/latest/Options.html?highlight=paste-logger#paste-logger
 
<http://uwsgi-docs.readthedocs.io/en/latest/Options.html?highlight=paste-logger#paste-logger>

uWSGI doesn’t automatically pick up your fileConfig logging otherwise.

(Basically unless you explicitly call fileConfig for your .ini right now uWSGI 
doesn’t do anything with your logging handlers/information)


> On Jan 19, 2017, at 10:17, Zsolt Ero <zsolt@gmail.com> wrote:
> 
> I'm just simply calling uwsgi uwsgi.ini and and it has the logto line in 
> there.
> 
> On 19 January 2017 at 18:16, Bert JW Regeer <xiste...@0x58.com> wrote:
>> Are you setting up logging explicitly?
>> 
>> uWSGI doesn’t automatically set up Python logging when you provide it a
>> paster ini file, how are you starting uWSGI?
>> 
>> Bert
>> 
>> On Jan 19, 2017, at 08:08, Zsolt Ero <zsolt@gmail.com> wrote:
>> 
>> I believe this is uWSGI specific, and might even be a bug in uWSGI, but
>> since many people are using uWSGI with Pyramid here, I'd be interested to
>> know how did you solve it.
>> 
>> 
>> I've migrated a project from Gunicorn to uWSGI. My problem is that my
>> previously set-up file-based logging is all bypassed / redirected now with
>> custom format discarded.
>> 
>> 
>> Previously it wrote to pyramid.log (and any other specific logs I had). Now,
>> after converting to uWSGI:
>> 
>> pyramid.log file is created but empty
>> every log is redirected to uwsgi.log, with all custom formatters discarded.
>> 
>> How can I make uWSGI not overwrite the whole, carefully set-up Python
>> logging system, and only output it's own log to uwsgi.log?
>> 
>> 
>> my uwsgi.ini:
>> 
>> [uwsgi]
>> paste = config:/home/app/web/app_web/production.ini
>> http-socket = :5000
>> uid = app
>> gid = app
>> 
>> master = true
>> processes = 16
>> enable-threads = true
>> harakiri = 60
>> harakiri-verbose = true
>> single-interpreter = true
>> 
>> die-on-term = true
>> vacuum = true
>> 
>> disable-logging = true
>> logto2 = /shared/logs/CURRENT/app/uwsgi.log
>> 
>> stats = /home/app/uwsgi_stats.socket
>> 
>> 
>> My logging setup is as follows:
>> 
>> [loggers]
>> keys = root, app_web, sqlalchemy
>> 
>> [handlers]
>> keys = filelog_pyramid
>> 
>> [formatters]
>> keys = generic
>> 
>> [logger_root]
>> level = WARN
>> handlers = filelog_pyramid
>> 
>> [logger_app_web]
>> level = WARN
>> handlers =
>> qualname = app_web
>> 
>> [logger_sqlalchemy]
>> level = WARN
>> handlers =
>> qualname = sqlalchemy.engine
>> 
>> [handler_filelog_pyramid]
>> class = FileHandler
>> args = ('/shared/logs/CURRENT/app/pyramid.log','a')
>> level = NOTSET
>> formatter = generic
>> 
>> [formatter_generic]
>> format = %(asctime)s %(levelname)-5.5s [%(name)s] %(message)s
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pylons-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/pylons-discuss/6c07825a-34f5-4542-b4c2-bf7759eda509%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "pylons-discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/pylons-discuss/CO5z2MD3iA0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> pylons-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/pylons-discuss/8DBCF3A1-E4AF-44A2-AD98-0E7A5381DC16%400x58.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Zsolt Ero]

I'm just simply calling uwsgi uwsgi.ini and and it has the logto line in there.

On 19 January 2017 at 18:16, Bert JW Regeer <xiste...@0x58.com> wrote:
> Are you setting up logging explicitly?
>
> uWSGI doesn’t automatically set up Python logging when you provide it a
> paster ini file, how are you starting uWSGI?
>
> Bert
>
> On Jan 19, 2017, at 08:08, Zsolt Ero <zsolt@gmail.com> wrote:
>
> I believe this is uWSGI specific, and might even be a bug in uWSGI, but
> since many people are using uWSGI with Pyramid here, I'd be interested to
> know how did you solve it.
>
>
> I've migrated a project from Gunicorn to uWSGI. My problem is that my
> previously set-up file-based logging is all bypassed / redirected now with
> custom format discarded.
>
>
> Previously it wrote to pyramid.log (and any other specific logs I had). Now,
> after converting to uWSGI:
>
> pyramid.log file is created but empty
> every log is redirected to uwsgi.log, with all custom formatters discarded.
>
> How can I make uWSGI not overwrite the whole, carefully set-up Python
> logging system, and only output it's own log to uwsgi.log?
>
>
> my uwsgi.ini:
>
> [uwsgi]
> paste = config:/home/app/web/app_web/production.ini
> http-socket = :5000
> uid = app
> gid = app
>
> master = true
> processes = 16
> enable-threads = true
> harakiri = 60
> harakiri-verbose = true
> single-interpreter = true
>
> die-on-term = true
> vacuum = true
>
> disable-logging = true
> logto2 = /shared/logs/CURRENT/app/uwsgi.log
>
> stats = /home/app/uwsgi_stats.socket
>
>
> My logging setup is as follows:
>
> [loggers]
> keys = root, app_web, sqlalchemy
>
> [handlers]
> keys = filelog_pyramid
>
> [formatters]
> keys = generic
>
> [logger_root]
> level = WARN
> handlers = filelog_pyramid
>
> [logger_app_web]
> level = WARN
> handlers =
> qualname = app_web
>
> [logger_sqlalchemy]
> level = WARN
> handlers =
> qualname = sqlalchemy.engine
>
> [handler_filelog_pyramid]
> class = FileHandler
> args = ('/shared/logs/CURRENT/app/pyramid.log','a')
> level = NOTSET
> formatter = generic
>
> [formatter_generic]
> format = %(asctime)s %(levelname)-5.5s [%(name)s] %(message)s
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/6c07825a-34f5-4542-b4c2-bf7759eda509%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "pylons-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pylons-discuss/CO5z2MD3iA0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/8DBCF3A1-E4AF-44A2-AD98-0E7A5381DC16%400x58.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CAKw-smCoGqReO7N7mBcbZH4yC2bft0LtW%3DPZdTd9rsWj7O-M4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] uWSGI logging issues with Pyramid

[Bert JW Regeer]

Are you setting up logging explicitly?

uWSGI doesn’t automatically set up Python logging when you provide it a paster 
ini file, how are you starting uWSGI?

Bert

> On Jan 19, 2017, at 08:08, Zsolt Ero <zsolt@gmail.com> wrote:
> 
> I believe this is uWSGI specific, and might even be a bug in uWSGI, but since 
> many people are using uWSGI with Pyramid here, I'd be interested to know how 
> did you solve it.
> 
> 
> 
> I've migrated a project from Gunicorn to uWSGI. My problem is that my 
> previously set-up file-based logging is all bypassed / redirected now with 
> custom format discarded.
> 
> 
> 
> Previously it wrote to pyramid.log (and any other specific logs I had). Now, 
> after converting to uWSGI:
> 
> pyramid.log file is created but empty
> every log is redirected to uwsgi.log, with all custom formatters discarded.
> How can I make uWSGI not overwrite the whole, carefully set-up Python logging 
> system, and only output it's own log to uwsgi.log?
> 
> 
> 
> my uwsgi.ini:
> 
> [uwsgi]
> paste = config:/home/app/web/app_web/production.ini
> http-socket = :5000
> uid = app
> gid = app
> 
> master = true
> processes = 16
> enable-threads = true
> harakiri = 60
> harakiri-verbose = true
> single-interpreter = true
> 
> die-on-term = true
> vacuum = true
> 
> disable-logging = true
> logto2 = /shared/logs/CURRENT/app/uwsgi.log
> 
> stats = /home/app/uwsgi_stats.socket
> 
> 
> My logging setup is as follows:
> 
> [loggers]
> keys = root, app_web, sqlalchemy
> 
> [handlers]
> keys = filelog_pyramid
> 
> [formatters]
> keys = generic
> 
> [logger_root]
> level = WARN
> handlers = filelog_pyramid
> 
> [logger_app_web]
> level = WARN
> handlers =
> qualname = app_web
> 
> [logger_sqlalchemy]
> level = WARN
> handlers =
> qualname = sqlalchemy.engine
> 
> [handler_filelog_pyramid]
> class = FileHandler
> args = ('/shared/logs/CURRENT/app/pyramid.log','a')
> level = NOTSET
> formatter = generic
> 
> [formatter_generic]
> format = %(asctime)s %(levelname)-5.5s [%(name)s] %(message)s
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com 
> <mailto:pylons-discuss+unsubscr...@googlegroups.com>.
> To post to this group, send email to pylons-discuss@googlegroups.com 
> <mailto:pylons-discuss@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/6c07825a-34f5-4542-b4c2-bf7759eda509%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/pylons-discuss/6c07825a-34f5-4542-b4c2-bf7759eda509%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/8DBCF3A1-E4AF-44A2-AD98-0E7A5381DC16%400x58.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] uWSGI logging issues with Pyramid

[Zsolt Ero]

I believe this is uWSGI specific, and might even be a bug in uWSGI, but 
since many people are using uWSGI with Pyramid here, I'd be interested to 
know how did you solve it.


I've migrated a project from Gunicorn to uWSGI. My problem is that my 
previously set-up file-based logging is all bypassed / redirected now with 
custom format discarded.


Previously it wrote to pyramid.log (and any other specific logs I had). 
Now, after converting to uWSGI:

   - pyramid.log file is created but empty
   - every log is redirected to uwsgi.log, with all custom formatters 
   discarded.

How can I make uWSGI not overwrite the whole, carefully set-up Python 
logging system, and only output it's own log to uwsgi.log?


my uwsgi.ini:

[uwsgi]
paste = config:/home/app/web/app_web/production.ini
http-socket = :5000
uid = app
gid = app

master = true
processes = 16
enable-threads = true
harakiri = 60
harakiri-verbose = true
single-interpreter = true

die-on-term = true
vacuum = true

disable-logging = true
logto2 = /shared/logs/CURRENT/app/uwsgi.log

stats = /home/app/uwsgi_stats.socket


My logging setup is as follows:

[loggers]
keys = root, app_web, sqlalchemy

[handlers]
keys = filelog_pyramid

[formatters]
keys = generic

[logger_root]
level = WARN
handlers = filelog_pyramid

[logger_app_web]
level = WARN
handlers =
qualname = app_web

[logger_sqlalchemy]
level = WARN
handlers =
qualname = sqlalchemy.engine

[handler_filelog_pyramid]
class = FileHandler
args = ('/shared/logs/CURRENT/app/pyramid.log','a')
level = NOTSET
formatter = generic

[formatter_generic]
format = %(asctime)s %(levelname)-5.5s [%(name)s] %(message)s

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/6c07825a-34f5-4542-b4c2-bf7759eda509%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Importing UWSGI inside __init__ while executing initializing scripts

[Srikanth Bemineni]

Hi,

How to import uwsgi while running Initialize db scripts. ?

I have been importing uwsgi module in my main __init__ app script to deal 
with forking issue faced by cassandra

import uwsgi 

from uwsgidecorators import *
@postfork
def connect_cassandra_client():
CaSession.connect(['127.0.0.1'], certificate='/path/here')
print("connection to cassandra made")


After adding uwsgi modules, none of the initialize scripts will be 
functional, since these scripts don't know how to import uwsgi, which is 
accessible only when ran from a uwsgi server.

Traceback (most recent call last):
  File 
"/home/izero/devel/xx/xx_env/bin/initialize_y_db", 
line 9, in 
load_entry_point('y==0.0', 'console_scripts', 
'initialize_y_db')()
  File 
"/home/izero/devel/xx/xx_env/lib/python3.4/site-packages/pkg_resources.py",
 
line 351, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File 
"/home/izero/devel/xx/xx_env/lib/python3.4/site-packages/pkg_resources.py",
 
line 2363, in load_entry_point
return ep.load()
  File 
"/home/izero/devel/xx/xx_env/lib/python3.4/site-packages/pkg_resources.py",
 
line 2088, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/home/izero/devel/xx/y/y/__init__.py", line 
26, in 
import uwsgi
ImportError: No module named 'uwsgi'

Does any one know how to deal with this issue ?

Srikanth

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] uwsgi + pyramid - SIGPIPE/IOError on 404?

[Jonathan Vanasco]

I was checking logs, and I noticed some odd behavior on a 404.

uwsgi/pyramid was listing a SIGPIPE + IOError

This was on an earlier version of uwsgi (1.9.14).  I upgraded to latest and 
everything works as it should.

I'd just like to make sure I'm not missing anything.  Has anyone 
experienced this before?  I couldn't find anything about this behavior in 
the uwsgi changelogs. i just want to make sure this was a uwsgi error that 
is now fixed by the upgrade, and not something from pyramid.



SIGPIPE: writing to a closed pipe/socket/fd (probably the client 
disconnected) on request /path/to/404 (ip 206.217.86.228) !!!
uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 260]
IOError: write error
[pid: 11156|app: 0|req: 27/39] 206.217.86.228 () {50 vars in 1964 bytes} 
[Fri Feb 12 20:28:00 2016] GET /path/to/404 => generated 0 bytes in 8 msecs 
(HTTP/1.1 404) 3 headers in 442 bytes (0 switches on core 0)

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] UWSGI + redis session Workers is taking too much time to die...NO MERCY !!!

[Srikanth Bemineni]

Hi,

It has been a very different learning experience with python webs apps 
coming from rails. There are lot of pieces , I am little bit confused where 
to post this question. Let me start with the framework.

I started to use UWSGI + redis(pyramid_redis_sessions) as external session 
application. After starting to use this, UWSGI is not able to kill the 
workers on exit.

I always get an error killing the workers 

"Fri Jan 22 12:49:31 2016 - worker 1 (pid: 4121) is taking too much time to 
die...NO MERCY !!!"

It took me a lot of time disabling different parts of the code to root 
cause redis session management as prime suspect.

Srikanth Bemineni


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Problems with debug toolbar when running via uwsgi

[Achim Domma]

Hi,

we have a problem with the debug toolbar. It is working fine, when the 
application is run via pserve on local development machines. When running 
the application using uwsgi, the debug toolbar fails quite often. Or one 
could also say, it works "sometimes", which of course makes it hard to 
reproduce and debug the problem. Our uwsgi command line is something like 
this:

uwsgi --chdir /pack/app --socket ${SOCKET} --chmod-socket=666 
/pack/app/ini/${INI}.ini

The ini section in the ini file looks like this:

 [uwsgi]
 master = True
 processes = 2
 threads = 2
 lazy = True
 lazy-apps = True
 paste = config:%p
 buffer-size = 65535
 enable-threads = True

Searching Google I was not able to find anything regarding uwsig + 
debugtoolbar. So either nobody is using it or we are the only ones having 
problems. ;-) So my first question would be: Is somebody else using the 
debug toolbar with a uwsgi hosted application? And of course the second: 
Any hint what might be wrong with our settings?

As I said, it is quite hard to reproduce the problem, so I can only provide 
quite vague additional details:

- I looks like some headers are messed up, when be passed to the debug 
toolbar and that seems to cause problems. But I have no idea where and how 
this is happening.
- I think, the problem started quite a while ago, when updating the debug 
toolbar to version 2. Looks like it is an isolated application internally, 
so the way it works, seems to have changed quite a lot. My guess would be, 
that the way uwsgi spawns processes is messing up things. Any hint in that 
direction would be very appreciated.

cheers,
Achim

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: Problems with debug toolbar when running via uwsgi

[Jonathan Vanasco]

On Thursday, January 21, 2016 at 3:57:30 AM UTC-5, Achim Domma wrote:
>
> we have a problem with the debug toolbar. It is working fine, when the 
> application is run via pserve on local development machines. When running 
> the application using uwsgi, the debug toolbar fails quite often. Or one 
> could also say, it works "sometimes", which of course makes it hard to 
> reproduce and debug the problem. 
>

What exactly is the problem?  "It doesn't work" is not a good description 
that anyone can help you with.  What did it do, how did that differ from 
what you expected.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Problems with debug toolbar when running via uwsgi

[Michael Merickel]

The debugtoolbar does not work in a multiprocess environment. Period. It
explicitly uses shared state in memory in order to show you the history of
requests. If you set "processes = 1" that may help but I am not familiar
with uwsgi configuration to say for sure. This issue[1] was created to
display a warning but has not been yet done.

https://github.com/Pylons/pyramid_debugtoolbar/issues/245

On Thu, Jan 21, 2016 at 2:57 AM, Achim Domma <ac...@uberresearch.com> wrote:

> Hi,
>
> we have a problem with the debug toolbar. It is working fine, when the
> application is run via pserve on local development machines. When running
> the application using uwsgi, the debug toolbar fails quite often. Or one
> could also say, it works "sometimes", which of course makes it hard to
> reproduce and debug the problem. Our uwsgi command line is something like
> this:
>
> uwsgi --chdir /pack/app --socket ${SOCKET} --chmod-socket=666
> /pack/app/ini/${INI}.ini
>
> The ini section in the ini file looks like this:
>
>  [uwsgi]
>  master = True
>  processes = 2
>  threads = 2
>  lazy = True
>  lazy-apps = True
>  paste = config:%p
>  buffer-size = 65535
>  enable-threads = True
>
> Searching Google I was not able to find anything regarding uwsig +
> debugtoolbar. So either nobody is using it or we are the only ones having
> problems. ;-) So my first question would be: Is somebody else using the
> debug toolbar with a uwsgi hosted application? And of course the second:
> Any hint what might be wrong with our settings?
>
> As I said, it is quite hard to reproduce the problem, so I can only
> provide quite vague additional details:
>
> - I looks like some headers are messed up, when be passed to the debug
> toolbar and that seems to cause problems. But I have no idea where and how
> this is happening.
> - I think, the problem started quite a while ago, when updating the debug
> toolbar to version 2. Looks like it is an isolated application internally,
> so the way it works, seems to have changed quite a lot. My guess would be,
> that the way uwsgi spawns processes is messing up things. Any hint in that
> direction would be very appreciated.
>
> cheers,
> Achim
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: Pyramid + uwsgi auto reload on source change

[Jonathan Vanasco]

On Thursday, January 14, 2016 at 6:55:10 PM UTC-5, Srikanth Bemineni wrote:
>
> from uwsgidecorators import postfork
>
> This is needed for initiating my cassandra connections on forking. 
> uwsgidecorator imports uwsgi, which will be only available when I run using 
> uwsgi. So when I start development from fresh checked out code. I need to 
> comment these lines. 
>

You can usually handle stuff like that where you have a `config` available, 
or use environment variables / a custom namespace.  then you conditionally 
do the imports and handle the atfork.

otherwise, i think you might get better performance by using waitress and 
manually starting/stopping a local uwsgi server when you want to test on 
that particular platform.

i do 99% of my testing on nginx->waitress, but can also toggle nginx->uwsgi 
for a few specific tests (such as the atfork stuff).

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: Pyramid + uwsgi auto reload on source change

[Srikanth Bemineni]

Hi,

I am currently using pserve for development. But this is making me do some 
changes to code when I move from development to production or vice versa. 
In my main app init.py I use the below imports

from uwsgidecorators import postfork

This is needed for initiating my cassandra connections on forking. 
uwsgidecorator imports uwsgi, which will be only available when I run using 
uwsgi. So when I start development from fresh checked out code. I need to 
comment these lines. 

I also feel like using pserve will not allow me to test any forking issue 
that may be seen during production, where I am thinking of using nginx + 
uwsgi.

Srikanth 


On Tuesday, January 12, 2016 at 12:22:24 PM UTC-6, Jason wrote:
>
>
> On Sunday, January 10, 2016 at 7:39:49 PM UTC-5, Srikanth Bemineni wrote:
>>
>>
>>
>> Hi ,
>>
>> Is there way we can make uwsgi reload on src change during development. I 
>> am looking for similar behaviour as pserve development.ini --reload
>>
>>
>>
> This doesn't answer your question, but I would recommend using pserve and 
> waitress for development. Although you should keep your development 
> environment as similar as possible to production, the ease of not 
> installing/configuring uWSGI on the development machine trumps the 
> consistency of environment. I've found that the during development there 
> are very rarely changes any of the uwsgi server configuration and it's much 
> faster to get setup if you don't have the dependency on uWSGI.
>
> -- Jason
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Pyramid + uwsgi auto reload on source change

[Bert JW Regeer]

http://chase-seibert.github.io/blog/2014/03/30/uwsgi-python-reload.html

A blog post that details some of this.

Bert

> On Jan 14, 2016, at 16:55, Srikanth Bemineni <bemineni.srika...@gmail.com> 
> wrote:
> 
> 
> Hi,
> 
> I am currently using pserve for development. But this is making me do some 
> changes to code when I move from development to production or vice versa. In 
> my main app init.py I use the below imports
> 
> from uwsgidecorators import postfork
> 
> This is needed for initiating my cassandra connections on forking. 
> uwsgidecorator imports uwsgi, which will be only available when I run using 
> uwsgi. So when I start development from fresh checked out code. I need to 
> comment these lines. 
> 
> I also feel like using pserve will not allow me to test any forking issue 
> that may be seen during production, where I am thinking of using nginx + 
> uwsgi.
> 
> Srikanth 
> 
> 
> On Tuesday, January 12, 2016 at 12:22:24 PM UTC-6, Jason wrote:
> 
> On Sunday, January 10, 2016 at 7:39:49 PM UTC-5, Srikanth Bemineni wrote:
> 
> 
> Hi ,
> 
> Is there way we can make uwsgi reload on src change during development. I am 
> looking for similar behaviour as pserve development.ini --reload
> 
> 
> 
> This doesn't answer your question, but I would recommend using pserve and 
> waitress for development. Although you should keep your development 
> environment as similar as possible to production, the ease of not 
> installing/configuring uWSGI on the development machine trumps the 
> consistency of environment. I've found that the during development there are 
> very rarely changes any of the uwsgi server configuration and it's much 
> faster to get setup if you don't have the dependency on uWSGI.
> 
> -- Jason
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME cryptographic signature

Re: [pylons-discuss] Pyramid + uwsgi auto reload on source change

[Bert JW Regeer]

http://uwsgi-docs.readthedocs.org/en/latest/HTTP.html
http://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html

And then there is:
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#py-autoreload

Mix and match, should get you to uWSGI being an HTTP server that you can hit.

Bert

> On Jan 14, 2016, at 16:55, Srikanth Bemineni <bemineni.srika...@gmail.com> 
> wrote:
> 
> 
> Hi,
> 
> I am currently using pserve for development. But this is making me do some 
> changes to code when I move from development to production or vice versa. In 
> my main app init.py I use the below imports
> 
> from uwsgidecorators import postfork
> 
> This is needed for initiating my cassandra connections on forking. 
> uwsgidecorator imports uwsgi, which will be only available when I run using 
> uwsgi. So when I start development from fresh checked out code. I need to 
> comment these lines. 
> 
> I also feel like using pserve will not allow me to test any forking issue 
> that may be seen during production, where I am thinking of using nginx + 
> uwsgi.
> 
> Srikanth 
> 
> 
> On Tuesday, January 12, 2016 at 12:22:24 PM UTC-6, Jason wrote:
> 
> On Sunday, January 10, 2016 at 7:39:49 PM UTC-5, Srikanth Bemineni wrote:
> 
> 
> Hi ,
> 
> Is there way we can make uwsgi reload on src change during development. I am 
> looking for similar behaviour as pserve development.ini --reload
> 
> 
> 
> This doesn't answer your question, but I would recommend using pserve and 
> waitress for development. Although you should keep your development 
> environment as similar as possible to production, the ease of not 
> installing/configuring uWSGI on the development machine trumps the 
> consistency of environment. I've found that the during development there are 
> very rarely changes any of the uwsgi server configuration and it's much 
> faster to get setup if you don't have the dependency on uWSGI.
> 
> -- Jason
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME cryptographic signature

[pylons-discuss] Re: uWSGI lazy-apps opinion

[Jason]

On Sunday, December 20, 2015 at 9:32:39 PM UTC-5, Srikanth Bemineni wrote:
>
>
> Hi ,
>
> I am working on getting the requirements for starting a new project ,using 
> pyramid framework. My project needs to work with both a SQL database(Mostly 
> probably MYSql) and Cassandra. I am currently at a stage where I am 
> deciding on the Cassandra connection issues. One of the issue that came 
> across is the same connection used in multiple fork issue, where multiple 
> forks of uWSGI using the same cassandra connection from the main scope and 
> timing out. The solution is to use @post_fork() decorator, 
>
> So, My question is , what is the best practice ? is it good to enable 
> lazy-apps, which is by default or disable lazy-apps. Will this also affect 
> SQAlchemy DB sessions ?. What are the cons and pros of the enabling and 
> disabling lazy-apps from pyramid perspective. Will forking  effect any 
> other services, that we use for a basic website, like payment system, email 
> services etc...
>
> Srikanth Bemineni
>
>
>
I use lazy-apps in production which acts the same as an application loaded 
by itself. The only issue I've run into is getting uWSGI to quit if one of 
the lazy-app instances fails to load. There was some configuration 
necessary to make uWSGI exit when that happens so that supervisor could 
detect and report it. This may not be necessary in your case anyway. The 
only reason we use lazy-apps is because we didn't want to add the post_fork 
logic our applications at the time we setup uWSGI.

It's unlikely that forking would cause any issues except with SQLAlchemy's 
session pool which requires the post_fork solution. I think it is libpq 
that restricts it from sharing the connections with forked processes. No 
issues should come up with any python libraries unless they specifically 
say they do not support forking.

My understanding is the only difference is the amount of memory usage. When 
forked some of the python process memory is shared reducing the total 
usage. There are some graceful reloading setups that need to take into 
consideration lazy-apps vs forking which you can read about at 
http://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html#preforking-vs-lazy-apps-vs-lazy
 
-- Jason

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: Pyramid + uwsgi auto reload on source change

[Jonathan Vanasco]

On Tuesday, January 12, 2016 at 1:22:24 PM UTC-5, Jason wrote:

This doesn't answer your question, but I would recommend using pserve and 
> waitress for development. 
>

We use nginx>uwsgi in production and nginx>pserve in development.  By 
keeping nginx consistent, it really minimized the differences between the 
two environments.  

There are still some differences, there are separate includes for each 
environment under nginx and uwsgi integrates differently than proxy-pass... 
but the deployments are similar enough that this works incredibly well.

tldr; use Jason's advice but you can also front port-80 with the same 
proxy/gateway/webserver in dev as you do in production.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: Pyramid + uwsgi auto reload on source change

[Jason]

On Sunday, January 10, 2016 at 7:39:49 PM UTC-5, Srikanth Bemineni wrote:
>
>
>
> Hi ,
>
> Is there way we can make uwsgi reload on src change during development. I 
> am looking for similar behaviour as pserve development.ini --reload
>
>
>
This doesn't answer your question, but I would recommend using pserve and 
waitress for development. Although you should keep your development 
environment as similar as possible to production, the ease of not 
installing/configuring uWSGI on the development machine trumps the 
consistency of environment. I've found that the during development there 
are very rarely changes any of the uwsgi server configuration and it's much 
faster to get setup if you don't have the dependency on uWSGI.

-- Jason

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Pyramid + uwsgi auto reload on source change

[Srikanth Bemineni]

Hi ,

Is there way we can make uwsgi reload on src change during development. I 
am looking for similar behaviour as pserve development.ini --reload

I found a django.utils. which detects file change, and we can initiate a 
uwsgi reload. Is there something similar in pyramid.

import uwsgifrom uwsgidecorators import timerfrom django.utils import autoreload
@timer(3)def change_code_gracefull_reload(sig):
if autoreload.code_changed():
uwsgi.reload()



Srikanth Bemineni

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] uWSGI lazy-apps opinion

[Srikanth Bemineni]

Hi ,

I am working on getting the requirements for starting a new project ,using 
pyramid framework. My project needs to work with both a SQL database(Mostly 
probably MYSql) and Cassandra. I am currently at a stage where I am 
deciding on the Cassandra connection issues. One of the issue that came 
across is the same connection used in multiple fork issue, where multiple 
forks of uWSGI using the same cassandra connection from the main scope and 
timing out. The solution is to use @post_fork() decorator, 

So, My question is , what is the best practice ? is it good to enable 
lazy-apps, which is by default or disable lazy-apps. Will this also affect 
SQAlchemy DB sessions ?. What are the cons and pros of the enabling and 
disabling lazy-apps from pyramid perspective. Will forking  effect any 
other services, that we use for a basic website, like payment system, email 
services etc...

Srikanth Bemineni


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Jeff Dairiki]

I'm not arguing that this is the best way, but as a data point, here's what
I do.

I use buildout to generate app.ini, as well as other config files,
including for uwsgi and supervisord, from templates (using
collective.recipe.template.)  I have several top-level buildout config
files, all of which specialize a common basic configuration: one for
deployment, one for staging, one for development.  All of the twiddly bits
(API keys, paths, logging config, etc.) are in one place (the top-level
buildout config file), and it is quite flexible (e.g. uwsgi for deployment,
pserve for development.)

On Sat, Nov 7, 2015 at 6:46 PM, Eric Hanchrow <eric.hanch...@gmail.com>
wrote:

> On Sat, Nov 7, 2015 at 12:56 PM, Jonathan Vanasco <jonat...@findmeon.com>
> wrote:
>
>>
>>
>> On Saturday, November 7, 2015 at 12:22:40 AM UTC-5, Mike Orr wrote:
>>>
>>> The ideal way would be to have a different INI file for different kinds
>>> of deployment
>>>
>>
>> I used to believe that... but as projects progressed, ini files got
>> larger and more difficult to maintain.  It's hard enough keeping
>> Production/Staging/Dev in step with one another.
>>
>> Splitting this out into "production-admin.ini" and
>> "production-non_admin.ini" files to declare a single variable would mean
>> having another file to update whenever other ini settings change.
>>
>> I assume that this is exactly why http://12factor.net/config says "
> Store config in the environment".
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Jonathan Vanasco]

On Tuesday, November 10, 2015 at 11:58:22 AM UTC-5, Jeff Dairiki wrote:
>
> I'm not arguing that this is the best way, but as a data point, here's 
> what I do. 
>

I'm mad I didn't think of this!  It's a great solution for me, because we 
already have a `fabric` script do much of the same as part of the 
deployment process.  [it re-builds static files from source, and generates 
some custom python files too] 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Jonathan Vanasco]

On Saturday, November 7, 2015 at 12:22:40 AM UTC-5, Mike Orr wrote:
>
> The ideal way would be to have a different INI file for different kinds of 
> deployment
>

I used to believe that... but as projects progressed, ini files got larger 
and more difficult to maintain.  It's hard enough keeping 
Production/Staging/Dev in step with one another.

Splitting this out into "production-admin.ini" and 
"production-non_admin.ini" files to declare a single variable would mean 
having another file to update whenever other ini settings change.  

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Mike Orr]

On Sat, Nov 7, 2015 at 12:56 PM, Jonathan Vanasco  wrote:

> Splitting this out into "production-admin.ini" and
> "production-non_admin.ini" files to declare a single variable would mean
> having another file to update whenever other ini settings change.

You can inherit from INI files. 'use = config:otherfile.ini'.

But, overall, INI files aren't the epitome of convenience.

-- 
Mike Orr 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Eric Hanchrow]

On Sat, Nov 7, 2015 at 12:56 PM, Jonathan Vanasco 
wrote:

>
>
> On Saturday, November 7, 2015 at 12:22:40 AM UTC-5, Mike Orr wrote:
>>
>> The ideal way would be to have a different INI file for different kinds
>> of deployment
>>
>
> I used to believe that... but as projects progressed, ini files got larger
> and more difficult to maintain.  It's hard enough keeping
> Production/Staging/Dev in step with one another.
>
> Splitting this out into "production-admin.ini" and
> "production-non_admin.ini" files to declare a single variable would mean
> having another file to update whenever other ini settings change.
>
> I assume that this is exactly why http://12factor.net/config says "
Store config in the environment".

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Mike Orr]

On Fri, Nov 6, 2015 at 1:39 PM, Jonathan Vanasco <jonat...@findmeon.com> wrote:

> * pyramid is deployed via uwsgi , which is controlled by supervisord.
> * uwsgi is invoked using the `--ini-paste--logged` argument, which which
> points to the "production.ini"
>
> I was thinking that the easiest way to enable/disable the admin routes would
> be to just set an environment variable in supervisord and just look for it
> in the app.  something like...
>
> [program:myapp-main]
> ...
> environment = MYAPP_DISABLE_ADMIN=1
> command = uwsgi --ini-paste-logged production.ini
>
> [program:myapp-admin]
> ...
> command = uwsgi --ini-paste-logged production.ini
>
> Does this sound like a good idea?  Has anyone else done this, or used
> another method?

I've done it for development; I have a settings-validation routine
that reads a couple optional environment variables to enable/disable
the debug toolbar without changing the INI file. The ideal way would
be to have a different INI file for different kinds of deployment, but
if you don't want to do that then an environment variable is a
reasonable choice. CGI uses environment variables for basic
information about the request, and the simplest form of authentication
is the REMOTE_USER variable.


-- 
Mike Orr <sluggos...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] fine-tuning a deployment under uwsgi + supervisord

[Jonathan Vanasco]

I'm trying to squeeze some more performance out of a cluster and an easy 
fix was segmenting out all the "admin" routes/views to be conditionally 
enabled.  (This saves enough MB per process that I can run a handful more 
processes. yay.)

I'm trying to figure out a good way to re-enable the "admin" routes though.

* pyramid is deployed via uwsgi , which is controlled by supervisord.  
* uwsgi is invoked using the `--ini-paste--logged` argument, which which 
points to the "production.ini"

I was thinking that the easiest way to enable/disable the admin routes 
would be to just set an environment variable in supervisord and just look 
for it in the app.  something like...

[program:myapp-main]
...
environment = MYAPP_DISABLE_ADMIN=1 
command = uwsgi --ini-paste-logged production.ini

[program:myapp-admin]
...
command = uwsgi --ini-paste-logged production.ini

Does this sound like a good idea?  Has anyone else done this, or used 
another method?

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] pyramid+uwsgi+nginx, unix socket connection refused

[Zagloj]

Hi, in your ini file you could try with ip:port in socket and listen to
that port from nginx, for example:
socket = 127.0.0.1:3031

Apart you could define home and config like this:
home = path_to_your_env
paste =
config:path_to_your_ini_file.ini

Hope this helps.

El Wed, 26 Feb 2014 02:31:39 -0800 (PST) Chung WONG wch...@gmail.com
escribió:
 Hi list,
 
 There is a socket connection refused problem in nginx(uwsgi?) that I
 have no idea how to fix it.
 I am not even sure if I am on the right track as I am following the 
 instructions here
 http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/ I hope someone
 can shed some light on it. Here are the related files
 
 nginx: 
 
 website.conf
 *server {*
 *listen  80;*
 *access_log  off;*
 *error_log   /var/log/nginx/http.error.log;*
 
 *charset utf-8;*
 *server_name example.local;*
 *location / {*
 *uwsgi_pass  unix:///tmp/uwsgi.sock;*
 *include uwsgi_params;*
 *}*
 *}*
 
 
 development.ini
 
 *[uwsgi]*
 *socket = /tmp/uwsgi.sock*
 *chmod-socket = 777*
 *chown-socket = www-data*
 *gid = www-data*
 *uid = www-data*
 *master = true*
 *processes = 4*
 *harakiri = 60*
 *harakiri-verbose = true*
 *limit-post = 65536*
 *post-buffering = 8192*
 *daemonize = ./uwsgi.log*
 *pidfile = ./pid_5000.pid*
 *listen = 256 *
 *max-requests = 1000*
 *reload-on-as = 128 *
 *reload-on-rss = 96*
 *no-orphans = true*
 *log-slow = true*
 *virtualenv = /home/chung/opt/Python-2.7.5/bin/env*
 
 uwsgi.log
 
  Starting uWSGI 2.0.1 (64bit) on [Wed Feb 26 21:26:42 2014] 
 *compiled with version: 4.8.2 on 24 February 2014 20:28:34*
 *os: Linux-3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)*
 *nodename: debian*
 *machine: x86_64*
 *clock source: unix*
 *pcre jit disabled*
 *detected number of CPU cores: 4*
 *current working
 directory: /home/chung/opt/Python-2.7.5/bin/env/example* *writing
 pidfile to ./pid_5000.pid* *detected binary
 path: /home/chung/opt/Python-2.7.5/bin/env/bin/uwsgi* *your processes
 number limit is 63212* *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)*
 *Listen queue size is greater than the system max net.core.somaxconn
 (128).*
 
 
 uwsgi.sock
 
 *-rw-r--r-- 1 www-data www-data0 Feb 26 21:19 uwsgi.sock*
 
 http.error.log
 
 *2014/02/26 21:28:33 [error] 6900#0: *8 connect() to
 unix:///tmp/uwsgi.sock failed (111: Connection refused) while
 connecting to upstream, client: 127.0.0.1, server: example.local,
 request: GET / HTTP/1.1, upstream:
 uwsgi://unix:///tmp/uwsgi.sock:, host: example.local* *2014/02/26
 21:28:33 [error] 6900#0: *8 connect() to unix:///tmp/uwsgi.sock
 failed (111: Connection refused) while connecting to upstream,
 client: 127.0.0.1, server: example.local, request: GET /favicon.ico
 HTTP/1.1, upstream: uwsgi://unix:///tmp/uwsgi.sock:, host:
 example.local*
 
 any help would be appreciated. Thanks
 

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[pylons-discuss] pyramid+uwsgi+nginx, unix socket connection refused

[Chung WONG]

Hi list,

There is a socket connection refused problem in nginx(uwsgi?) that I have 
no idea how to fix it.
I am not even sure if I am on the right track as I am following the 
instructions here http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/
I hope someone can shed some light on it.
Here are the related files

nginx: 

website.conf
*server {*
*listen  80;*
*access_log  off;*
*error_log   /var/log/nginx/http.error.log;*

*charset utf-8;*
*server_name example.local;*
*location / {*
*uwsgi_pass  unix:///tmp/uwsgi.sock;*
*include uwsgi_params;*
*}*
*}*


development.ini

*[uwsgi]*
*socket = /tmp/uwsgi.sock*
*chmod-socket = 777*
*chown-socket = www-data*
*gid = www-data*
*uid = www-data*
*master = true*
*processes = 4*
*harakiri = 60*
*harakiri-verbose = true*
*limit-post = 65536*
*post-buffering = 8192*
*daemonize = ./uwsgi.log*
*pidfile = ./pid_5000.pid*
*listen = 256 *
*max-requests = 1000*
*reload-on-as = 128 *
*reload-on-rss = 96*
*no-orphans = true*
*log-slow = true*
*virtualenv = /home/chung/opt/Python-2.7.5/bin/env*

uwsgi.log

 Starting uWSGI 2.0.1 (64bit) on [Wed Feb 26 21:26:42 2014] 
*compiled with version: 4.8.2 on 24 February 2014 20:28:34*
*os: Linux-3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)*
*nodename: debian*
*machine: x86_64*
*clock source: unix*
*pcre jit disabled*
*detected number of CPU cores: 4*
*current working directory: /home/chung/opt/Python-2.7.5/bin/env/example*
*writing pidfile to ./pid_5000.pid*
*detected binary path: /home/chung/opt/Python-2.7.5/bin/env/bin/uwsgi*
*your processes number limit is 63212*
*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)*
*Listen queue size is greater than the system max net.core.somaxconn (128).*


uwsgi.sock

*-rw-r--r-- 1 www-data www-data0 Feb 26 21:19 uwsgi.sock*

http.error.log

*2014/02/26 21:28:33 [error] 6900#0: *8 connect() to unix:///tmp/uwsgi.sock 
failed (111: Connection refused) while connecting to upstream, client: 
127.0.0.1, server: example.local, request: GET / HTTP/1.1, upstream: 
uwsgi://unix:///tmp/uwsgi.sock:, host: example.local*
*2014/02/26 21:28:33 [error] 6900#0: *8 connect() to unix:///tmp/uwsgi.sock 
failed (111: Connection refused) while connecting to upstream, client: 
127.0.0.1, server: example.local, request: GET /favicon.ico HTTP/1.1, 
upstream: uwsgi://unix:///tmp/uwsgi.sock:, host: example.local*

any help would be appreciated. Thanks

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [pylons-discuss] pyramid+uwsgi+nginx, unix socket connection refused

[Roberto De Ioris]

 Hi list,

 There is a socket connection refused problem in nginx(uwsgi?) that I have
 no idea how to fix it.
 I am not even sure if I am on the right track as I am following the
 instructions here http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/
 I hope someone can shed some light on it.
 Here are the related files

 nginx:

 website.conf
 *server {*
 *listen  80;*
 *access_log  off;*
 *error_log   /var/log/nginx/http.error.log;*

 *charset utf-8;*
 *server_name example.local;*
 *location / {*
 *uwsgi_pass  unix:///tmp/uwsgi.sock;*
 *include uwsgi_params;*
 *}*
 *}*


 development.ini

 *[uwsgi]*
 *socket = /tmp/uwsgi.sock*
 *chmod-socket = 777*
 *chown-socket = www-data*
 *gid = www-data*
 *uid = www-data*
 *master = true*
 *processes = 4*
 *harakiri = 60*
 *harakiri-verbose = true*
 *limit-post = 65536*
 *post-buffering = 8192*
 *daemonize = ./uwsgi.log*
 *pidfile = ./pid_5000.pid*
 *listen = 256 *
 *max-requests = 1000*
 *reload-on-as = 128 *
 *reload-on-rss = 96*
 *no-orphans = true*
 *log-slow = true*
 *virtualenv = /home/chung/opt/Python-2.7.5/bin/env*

 uwsgi.log

  Starting uWSGI 2.0.1 (64bit) on [Wed Feb 26 21:26:42 2014] 
 *compiled with version: 4.8.2 on 24 February 2014 20:28:34*
 *os: Linux-3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)*
 *nodename: debian*
 *machine: x86_64*
 *clock source: unix*
 *pcre jit disabled*
 *detected number of CPU cores: 4*
 *current working directory: /home/chung/opt/Python-2.7.5/bin/env/example*
 *writing pidfile to ./pid_5000.pid*
 *detected binary path: /home/chung/opt/Python-2.7.5/bin/env/bin/uwsgi*
 *your processes number limit is 63212*
 *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)*
 *Listen queue size is greater than the system max net.core.somaxconn
 (128).*


Here your uWSGI process died, so it is normal nginx cannot connect to it


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

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[pylons-discuss] Re: pyramid+uwsgi+nginx, unix socket connection refused

[Chung WONG]

thanks Roberto, I removed the listen param in the .ini and that particular 
error has gone.
However, there are another two errors which I think they are related to 
Paste.

 Starting uWSGI 2.0.1 (64bit) on [Wed Feb 26 22:02:36 2014] 
*compiled with version: 4.8.2 on 24 February 2014 20:28:34*
*os: Linux-3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)*
*nodename: debian*
*machine: x86_64*
*clock source: unix*
*pcre jit disabled*
*detected number of CPU cores: 4*
*current working directory: /home/chung/opt/Python-2.7.5/bin/env/example*
*writing pidfile to ./pid_5000.pid*
*detected binary path: /home/chung/opt/Python-2.7.5/bin/env/bin/uwsgi*
*your processes number limit is 63212*
*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 bound to UNIX address /tmp/uwsgi.sock fd 3*
*Python version: 2.7.5 (default, Jun 17 2013, 01:43:20)  [GCC 4.7.2]*
*Set PythonHome to /home/chung/opt/Python-2.7.5/bin/env*
 Python threads support is disabled. You can enable it with 
--enable-threads 
*Python main interpreter initialized at 0xb938f0*
*your server socket listen backlog is limited to 100 connections*
*your mercy for graceful operations on workers is 60 seconds*
*mapped 404760 bytes (395 KB) for 4 cores*
 Operational MODE: preforking 
*Loading paste environment: 
config:/home/chung/opt/Python-2.7.5/bin/env/example/development.ini*
*ImportError: No module named script.util.logging_config*
*ImportError: No module named deploy*

When I run 

*../bin/uwsgi --ini-paste-logged development.ini*
It produce the above error, while if i run without the log

*../bin/uwsgi --ini-paste development.ini*
This error* ImportError: No module named script.util.logging_config *went 
away, while the remaining one is still there.

I've checked my virtualenv does have* paste.deploy* as I can import 
paste.deploy but I couldn't find* paste.script.util.logging_config*

Did I miss some paste extra modules?

Thanks again 



-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[pylons-discuss] Re: pyramid+uwsgi+nginx, unix socket connection refused

[Chung WONG]

For some reason, after upgraded PasteDeploy from 1.5.0 to 1.5.2, both 
errors have gone.

Problem Solved!

Thanks
On Wednesday, February 26, 2014 9:31:39 PM UTC+11, Chung WONG wrote:

 Hi list,

 There is a socket connection refused problem in nginx(uwsgi?) that I have 
 no idea how to fix it.
 I am not even sure if I am on the right track as I am following the 
 instructions here http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/
 I hope someone can shed some light on it.
 Here are the related files

 nginx: 

 website.conf
 *server {*
 *listen  80;*
 *access_log  off;*
 *error_log   /var/log/nginx/http.error.log;*

 *charset utf-8;*
 *server_name example.local;*
 *location / {*
 *uwsgi_pass  unix:///tmp/uwsgi.sock;*
 *include uwsgi_params;*
 *}*
 *}*


 development.ini

 *[uwsgi]*
 *socket = /tmp/uwsgi.sock*
 *chmod-socket = 777*
 *chown-socket = www-data*
 *gid = www-data*
 *uid = www-data*
 *master = true*
 *processes = 4*
 *harakiri = 60*
 *harakiri-verbose = true*
 *limit-post = 65536*
 *post-buffering = 8192*
 *daemonize = ./uwsgi.log*
 *pidfile = ./pid_5000.pid*
 *listen = 256 *
 *max-requests = 1000*
 *reload-on-as = 128 *
 *reload-on-rss = 96*
 *no-orphans = true*
 *log-slow = true*
 *virtualenv = /home/chung/opt/Python-2.7.5/bin/env*

 uwsgi.log

  Starting uWSGI 2.0.1 (64bit) on [Wed Feb 26 21:26:42 2014] 
 *compiled with version: 4.8.2 on 24 February 2014 20:28:34*
 *os: Linux-3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)*
 *nodename: debian*
 *machine: x86_64*
 *clock source: unix*
 *pcre jit disabled*
 *detected number of CPU cores: 4*
 *current working directory: /home/chung/opt/Python-2.7.5/bin/env/example*
 *writing pidfile to ./pid_5000.pid*
 *detected binary path: /home/chung/opt/Python-2.7.5/bin/env/bin/uwsgi*
 *your processes number limit is 63212*
 *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)*
 *Listen queue size is greater than the system max net.core.somaxconn 
 (128).*


 uwsgi.sock

 *-rw-r--r-- 1 www-data www-data0 Feb 26 21:19 uwsgi.sock*

 http.error.log

 *2014/02/26 21:28:33 [error] 6900#0: *8 connect() to 
 unix:///tmp/uwsgi.sock failed (111: Connection refused) while connecting to 
 upstream, client: 127.0.0.1, server: example.local, request: GET / 
 HTTP/1.1, upstream: uwsgi://unix:///tmp/uwsgi.sock:, host: 
 example.local*
 *2014/02/26 21:28:33 [error] 6900#0: *8 connect() to 
 unix:///tmp/uwsgi.sock failed (111: Connection refused) while connecting to 
 upstream, client: 127.0.0.1, server: example.local, request: GET 
 /favicon.ico HTTP/1.1, upstream: uwsgi://unix:///tmp/uwsgi.sock:, host: 
 example.local*

 any help would be appreciated. Thanks



-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem running pyramid 1.4 project with nginx+uwsgi

[askel]

Michael,

It seems to me that while Nginx is configured to connect to uwsgi via 
socket file /tmp/uwsgi.sock you make uwsgi bind/listen to TCP port 8080.

- Alex

On Saturday, April 20, 2013 5:46:47 PM UTC-4, Michael wrote:

 Hi, I get Internal Server Error running a pyramid sqlalchemy scaffold 
 app inside a virtualenv when I try to run it with uwsgi. However, when I 
 run it with pserve, I get no issues and the orange pyramid hello world 
 displays OK in Safari.

 I'm using nginx 1.2.8, uWSGI 1.9.6, pyramid 1.4.


 Here are my nginx settings:
 nginx.conf: https://gist.github.com/mazzaroth/a6b1ca76578f88189a74

 Pyramid app settings:
 pyramid development.ini: 
 https://gist.github.com/mazzaroth/a21f15dc9c72fa882699

 in /private/etc/nginx/sites-available/test1:

 server {
 listen  8080;
 access_log  off;
 error_log   /var/log/nginx/http.error.log;

 charset utf-8;
 location / {
 uwsgi_pass  unix:///tmp/uwsgi.sock;
 include uwsgi_params;
 }
 }

  ln -sf /etc/nginx/sites-available/demo /etc/nginx/sites-enabled/demo

 restart nginx


 ~~ uwsgi

  cd ~/webapps/env1/test1

  uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini

  ps aux | grep uwsgi

 michael24134   0.0  0.1  2446036   2608   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24133   0.0  0.1  2446036   2608   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24132   0.0  0.1  2446952   4396   ??  S 3:15pm   
 0:00.03 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24139   0.0  0.0  2432768452 s002  R+3:15pm   
 0:00.00 grep uwsgi
 michael24137   0.0  0.0  2446952340   ??  S 3:15pm   
 0:00.00 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24136   0.0  0.1  2446036   2608   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24135   0.0  0.1  2446036   2604   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini


 However, when I go to localhost:8080, I get Internal Server Error

 Much of what I've done so far is based on this tut:

 http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/

 Any help would be greatly appreciated..

 Michael




-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem running pyramid 1.4 project with nginx+uwsgi

[Cornelius Kölbel]

Hi Michael,
In case of an internal server error you should take a look at your web servers 
error log.

Kind regards
Cornelius 
--



Am 20.04.2013 um 23:46 schrieb Mazzaroth M. taomaili...@gmail.com:

 Hi, I get Internal Server Error running a pyramid sqlalchemy scaffold app 
 inside a virtualenv when I try to run it with uwsgi. However, when I run it 
 with pserve, I get no issues and the orange pyramid hello world displays OK 
 in Safari.
 
 I'm using nginx 1.2.8, uWSGI 1.9.6, pyramid 1.4.
 
 
 Here are my nginx settings:
 nginx.conf: https://gist.github.com/mazzaroth/a6b1ca76578f88189a74
 
 Pyramid app settings:
 pyramid development.ini: 
 https://gist.github.com/mazzaroth/a21f15dc9c72fa882699
 
 in /private/etc/nginx/sites-available/test1:
 
 server {
 listen  8080;
 access_log  off;
 error_log   /var/log/nginx/http.error.log;
 
 charset utf-8;
 location / {
 uwsgi_pass  unix:///tmp/uwsgi.sock;
 include uwsgi_params;
 }
 }
 
  ln -sf /etc/nginx/sites-available/demo /etc/nginx/sites-enabled/demo
 
 restart nginx
 
 
 ~~ uwsgi
 
  cd ~/webapps/env1/test1
 
  uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 
  ps aux | grep uwsgi
 
 michael24134   0.0  0.1  2446036   2608   ??  S 3:15pm   0:00.01 
 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 michael24133   0.0  0.1  2446036   2608   ??  S 3:15pm   0:00.01 
 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 michael24132   0.0  0.1  2446952   4396   ??  S 3:15pm   0:00.03 
 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 michael24139   0.0  0.0  2432768452 s002  R+3:15pm   0:00.00 
 grep uwsgi
 michael24137   0.0  0.0  2446952340   ??  S 3:15pm   0:00.00 
 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 michael24136   0.0  0.1  2446036   2608   ??  S 3:15pm   0:00.01 
 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 michael24135   0.0  0.1  2446036   2604   ??  S 3:15pm   0:00.01 
 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini
 
 
 However, when I go to localhost:8080, I get Internal Server Error
 
 Much of what I've done so far is based on this tut:
 
 http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/
 
 Any help would be greatly appreciated..
 
 Michael
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Problem running pyramid 1.4 project with nginx+uwsgi

[Mazzaroth M.]

Hi, I get Internal Server Error running a pyramid sqlalchemy scaffold app
inside a virtualenv when I try to run it with uwsgi. However, when I run it
with pserve, I get no issues and the orange pyramid hello world displays OK
in Safari.

I'm using nginx 1.2.8, uWSGI 1.9.6, pyramid 1.4.


Here are my nginx settings:
nginx.conf: https://gist.github.com/mazzaroth/a6b1ca76578f88189a74

Pyramid app settings:
pyramid development.ini:
https://gist.github.com/mazzaroth/a21f15dc9c72fa882699

in /private/etc/nginx/sites-available/test1:

server {
listen  8080;
access_log  off;
error_log   /var/log/nginx/http.error.log;

charset utf-8;
location / {
uwsgi_pass  unix:///tmp/uwsgi.sock;
include uwsgi_params;
}
}

 ln -sf /etc/nginx/sites-available/demo /etc/nginx/sites-enabled/demo

restart nginx


~~ uwsgi

 cd ~/webapps/env1/test1

 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini

 ps aux | grep uwsgi

michael24134   0.0  0.1  2446036   2608   ??  S 3:15pm
0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini
development.ini
michael24133   0.0  0.1  2446036   2608   ??  S 3:15pm
0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini
development.ini
michael24132   0.0  0.1  2446952   4396   ??  S 3:15pm
0:00.03 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini
development.ini
michael24139   0.0  0.0  2432768452 s002  R+3:15pm
0:00.00 grep uwsgi
michael24137   0.0  0.0  2446952340   ??  S 3:15pm
0:00.00 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini
development.ini
michael24136   0.0  0.1  2446036   2608   ??  S 3:15pm
0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini
development.ini
michael24135   0.0  0.1  2446036   2604   ??  S 3:15pm
0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini
development.ini


However, when I go to localhost:8080, I get Internal Server Error

Much of what I've done so far is based on this tut:

http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/

Any help would be greatly appreciated..

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem running pyramid 1.4 project with nginx+uwsgi

[Wyatt Baldwin]

Also, you probably don't want the --http option when using uwgi_pass w/ a 
socket.

On Saturday, April 20, 2013 2:46:47 PM UTC-7, Michael wrote:

 Hi, I get Internal Server Error running a pyramid sqlalchemy scaffold 
 app inside a virtualenv when I try to run it with uwsgi. However, when I 
 run it with pserve, I get no issues and the orange pyramid hello world 
 displays OK in Safari.

 I'm using nginx 1.2.8, uWSGI 1.9.6, pyramid 1.4.


 Here are my nginx settings:
 nginx.conf: https://gist.github.com/mazzaroth/a6b1ca76578f88189a74

 Pyramid app settings:
 pyramid development.ini: 
 https://gist.github.com/mazzaroth/a21f15dc9c72fa882699

 in /private/etc/nginx/sites-available/test1:

 server {
 listen  8080;
 access_log  off;
 error_log   /var/log/nginx/http.error.log;

 charset utf-8;
 location / {
 uwsgi_pass  unix:///tmp/uwsgi.sock;
 include uwsgi_params;
 }
 }

  ln -sf /etc/nginx/sites-available/demo /etc/nginx/sites-enabled/demo

 restart nginx


 ~~ uwsgi

  cd ~/webapps/env1/test1

  uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini development.ini

  ps aux | grep uwsgi

 michael24134   0.0  0.1  2446036   2608   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24133   0.0  0.1  2446036   2608   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24132   0.0  0.1  2446952   4396   ??  S 3:15pm   
 0:00.03 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24139   0.0  0.0  2432768452 s002  R+3:15pm   
 0:00.00 grep uwsgi
 michael24137   0.0  0.0  2446952340   ??  S 3:15pm   
 0:00.00 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24136   0.0  0.1  2446036   2608   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini
 michael24135   0.0  0.1  2446036   2604   ??  S 3:15pm   
 0:00.01 uwsgi -H /Users/michael/webapps/env1 --http :8080 --ini 
 development.ini


 However, when I go to localhost:8080, I get Internal Server Error

 Much of what I've done so far is based on this tut:

 http://liangsun.org/posts/pyramid-nginx-uwsgi-mysql/

 Any help would be greatly appreciated..

 Michael




-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using Pyramid with Nginx and uWSGI

[Jonah Dahlquist]

Ahh, that first tutorial is great, I wish I had it at the beginning, I 
would have been up to speed much quicker :)


On Saturday, July 28, 2012 9:47:22 PM UTC-7, Craig Younkins wrote:

 You'll want to follow this tutorial to create your first Pyramid project - 
 http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/project.html#project-narr

 When you want to deploy it using uwsgi, follow up to step 7 in this 
 tutorial - 
 http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/tutorials/modwsgi/index.html#modwsgi-tutorial

 In your uwsgi ini, 'file' will refer to 'pyramid.wsgi' in the tutorial 
 above, since it will have the wsgi application (callable = 'application')

 Hope that helps!

 Craig Younkins


 On Sat, Jul 28, 2012 at 11:08 PM, Jonah Dahlquist 
 jonah...@gmail.comjavascript:
  wrote:

 Hello, world!

 I'm coming into the Python world from a PHP background.  I'm trying to 
 get a working Pyramid application working on my own machine, and I've 
 almost made it.  I have nginx and uWSGI running, and can call a Python 
 script from the browser successfully.  However, lots of research, reading 
 documentation, and even reading through the starter project code has 
 failed to make it clear to me how to connect Pyramid to wsgi.  The script 
 looks like this:

 def application(env, start_response):
 start_response('200 OK', [('Content-Type', 'text/html')])
 return Hello universe!

 The INI configuration file for uWSGI is as follows:

 [uwsgi]
 socket = /tmp/uwsgi.sock
 master = true
 processes = 4
 file = ./app.py
 callable = application
 daemonize = ./uwsgi.log
 pidfile = /tmp/app_process.pid
 virtualenv = /home/jonah/.virtualenvs/test

 So a request to http://localhost/ in the browser gives me Hello 
 Universe!.  How can I modify my script/uWSGI configuration to run Pyramid 
 instead?  Thanks for your help.

 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/pylons-discuss/-/xW1HspiacSYJ.
 To post to this group, send email to pylons-...@googlegroups.comjavascript:
 .
 To unsubscribe from this group, send email to 
 pylons-discus...@googlegroups.com javascript:.
 For more options, visit this group at 
 http://groups.google.com/group/pylons-discuss?hl=en.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/l7v9Al43A04J.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Using Pyramid with Nginx and uWSGI

[Jonah Dahlquist]

Sweet, Simon, that's exactly what I need.  Thanks so much, I'm quite 
enjoying Python so far, and I have a working starter project now.


On Monday, July 30, 2012 2:07:44 AM UTC-7, Simon wrote:

 When you have a working pyramid starter project, this might be helpful... 

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

 And this.. 

 http://pythonpaste.org/deploy/ 

 You can init like this; 

 $ uwsgi development.ini 

 provided you have this line in your .ini 

  [uwsgi] 
  paste = config:absolute_project_path/development.ini 

 Alternatively, you can combine the ``ini`` and ``paste`` config action, 
 and remove the need to reference your .ini file twice. 

 $ uwsgi --ini-paste development.ini 

 The features above support having combined .ini files, or a single .ini 
 files that configures multiple apps. 

 ps. You don't need that ``callable`` line because uwsgi reads your paste 
 .ini file and derives from ``use = egg:MyProject``, which is short-hand for 
 ``egg:MyProject#main`` - ``main`` being the callable in your project's 
 ``__init__.py``. I write mine in full as I prefer to have as little implied 
 config as possible. 


 On 29 Jul 2012, at 05:47, Craig Younkins wrote: 

  You'll want to follow this tutorial to create your first Pyramid project 
 - 
 http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/project.html#project-narr
  
  
  When you want to deploy it using uwsgi, follow up to step 7 in this 
 tutorial - 
 http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/tutorials/modwsgi/index.html#modwsgi-tutorial
  
  
  In your uwsgi ini, 'file' will refer to 'pyramid.wsgi' in the tutorial 
 above, since it will have the wsgi application (callable = 'application') 
  
  Hope that helps! 
  
  Craig Younkins 
  
  
  On Sat, Jul 28, 2012 at 11:08 PM, Jonah Dahlquist 
  jonah...@gmail.comjavascript: 
 wrote: 
  Hello, world! 
  
  I'm coming into the Python world from a PHP background.  I'm trying to 
 get a working Pyramid application working on my own machine, and I've 
 almost made it.  I have nginx and uWSGI running, and can call a Python 
 script from the browser successfully.  However, lots of research, reading 
 documentation, and even reading through the starter project code has 
 failed to make it clear to me how to connect Pyramid to wsgi.  The script 
 looks like this: 
  
  def application(env, start_response): 
  start_response('200 OK', [('Content-Type', 'text/html')]) 
  return Hello universe! 
  
  The INI configuration file for uWSGI is as follows: 
  
  [uwsgi] 
  socket = /tmp/uwsgi.sock 
  master = true 
  processes = 4 
  file = ./app.py 
  callable = application 
  daemonize = ./uwsgi.log 
  pidfile = /tmp/app_process.pid 
  virtualenv = /home/jonah/.virtualenvs/test 
  
  So a request to http://localhost/ in the browser gives me Hello 
 Universe!.  How can I modify my script/uWSGI configuration to run Pyramid 
 instead?  Thanks for your help. 
  
  -- 
  You received this message because you are subscribed to the Google 
 Groups pylons-discuss group. 
  To view this discussion on the web visit 
 https://groups.google.com/d/msg/pylons-discuss/-/xW1HspiacSYJ. 
  To post to this group, send email to 
  pylons-...@googlegroups.comjavascript:. 

  To unsubscribe from this group, send email to 
 pylons-discus...@googlegroups.com javascript:. 
  For more options, visit this group at 
 http://groups.google.com/group/pylons-discuss?hl=en. 
  
  
  -- 
  You received this message because you are subscribed to the Google 
 Groups pylons-discuss group. 
  To post to this group, send email to 
  pylons-...@googlegroups.comjavascript:. 

  To unsubscribe from this group, send email to 
 pylons-discus...@googlegroups.com javascript:. 
  For more options, visit this group at 
 http://groups.google.com/group/pylons-discuss?hl=en. 



-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/mzV73rvdRpYJ.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Using Pyramid with Nginx and uWSGI

[Jonathan Vanasco]

check out my last post in this thread:

http://groups.google.com/group/pylons-discuss/browse_thread/thread/2de9e2661230c999/b93b702bb42b4fc2

might help you get going a bit faster

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

uwsgi and forking

[Jonathan Vanasco]

I had some code that worked with Crypto and wasn't initially
compatible with uwsgi...

the fix was to call Crypto.Random's atfork() . thankfully uwsgi has a
post_fork_hook that made this simple

I don't always run under uwsgi though.  does the implementation I used
below look okay - or does anyone know of a more pyramid-esque method ?


myapp/__init__.py
==
try:
import uwsgi
from Crypto.Random import atfork
def post_fork_hook():
atfork()
uwsgi.post_fork_hook = post_fork_hook
except:
pass
==

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Using Pyramid with Nginx and uWSGI

[Jonah Dahlquist]

Hello, world!

I'm coming into the Python world from a PHP background.  I'm trying to get 
a working Pyramid application working on my own machine, and I've almost 
made it.  I have nginx and uWSGI running, and can call a Python script from 
the browser successfully.  However, lots of research, reading 
documentation, and even reading through the starter project code has 
failed to make it clear to me how to connect Pyramid to wsgi.  The script 
looks like this:

def application(env, start_response):
start_response('200 OK', [('Content-Type', 'text/html')])
return Hello universe!

The INI configuration file for uWSGI is as follows:

[uwsgi]
socket = /tmp/uwsgi.sock
master = true
processes = 4
file = ./app.py
callable = application
daemonize = ./uwsgi.log
pidfile = /tmp/app_process.pid
virtualenv = /home/jonah/.virtualenvs/test

So a request to http://localhost/ in the browser gives me Hello 
Universe!.  How can I modify my script/uWSGI configuration to run Pyramid 
instead?  Thanks for your help.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/xW1HspiacSYJ.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Pyramid paste/logging/uwsgi problem...

[Vlad K.]

I think this is getting old

Please, how do I run a Pyramid 1.3 app, full with logging as specified 
in the .ini file, under uWSGI.




Thanks.

--

.oO V Oo.

--
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pyramid paste/logging/uwsgi problem...

[Roberto De Ioris]

 On 07/13/2012 09:41 PM, Roberto De Ioris wrote:
 I think this is getting old

 Please, how do I run a Pyramid 1.3 app, full with logging as specified
 in the .ini file, under uWSGI.

 uwsgi --http :8080 --ini-paste-logged deployement.ini

 (substitute deployment.ini with your config file).

 You have to use at least uWSGI 1.2



 I must admit I didn't try directly from command line, but I use uwsgi
 config INI because of vassals and several sites run under same uwsgi
 server, so I like to drop them in /etc/uwsgi.d/ which I configured in my
 custom sysvinit script.

 So this is my config INI (not the paste INI):

 [uwsgi]
 master = true
 processes = 1
 enable-threads = true
 single-interpreter = true
 threads = 2
 uid = siteuser
 gid = siteuser
 paste = config:/home/siteuser/Sitename/production.ini
 chdir = /home/siteuser
 virtualenv = /home/siteuser/Sitename/virtualenv
 socket = /tmp/uwsgi/uwsgi-sitename.socket


ini-paste-logged does not work in 'vassal' mode.

Use --paste-logger

paste = config:/home/siteuser/Sitename/production.ini
paste-logger = /home/siteuser/Sitename/production.ini

or better:

mypaste = /home/siteuser/Sitename/production.ini
paste = config:%(mypaste)
paste-logger = %(mypaste)



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

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi emperor mode and pyramid

[doggy]

Thank you, Roberto!

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/x_8o6O34lNsJ.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi emperor mode and pyramid

[doggy]

Thank you!
Now I'm happy :)

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/TQTJOd1ZmrMJ.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

uwsgi emperor mode and pyramid

[doggy]

Hello!
When i try to run my pyramid application with uwsgi in emperor mode,
in browser i have error:

uWSGI Error
Python application not found

When i run without --emperor all works good.


Here is detail trouble description:
in my virtualenv i do:

bin/easy_install pyramid
bin/easy_install uwsgi
bin/pcreate -t starter myproject
cd myproject/
../bin/python setup.py develop

in development.ini a add this lines
[uwsgi]
virtualenv = /sites-root/doggy/uwsgi/test/env
http-socket = 0.0.0.0:8080
master = true
processes = 4

when i run
../bin/uwsgi --ini-paste development.ini
all works good, in browser i see demo application

when i run
../bin/uwsgi --master --emperor development.ini
in browser i see uWSGI Error Python application not found


*** Starting uWSGI 1.2.3 (64bit) on [Tue May 29 14:43:20 2012] ***
compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 May 2012
14:28:04
detected number of CPU cores: 4
current working directory: /mnt/iscsi/appro-3-20gb/sites-root/doggy/
uwsgi/test/env/myproject
detected binary path: /mnt/iscsi/appro-3-20gb/sites-root/doggy/uwsgi/
test/env/bin/uwsgi
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
*** starting uWSGI Emperor ***
Python version: 2.6.6 (r266:84292, Dec  7 2011, 20:48:22)  [GCC 4.4.6
20110731 (Red Hat 4.4.6-3)]
*** Python threads support is disabled. You can enable it with --
enable-threads ***
Python main interpreter initialized at 0xb5bfe0
*** Operational MODE: no-workers ***
spawned uWSGI master process (pid: 22551)
*** has_emperor mode detected (fd: 5) ***
[uWSGI] getting INI configuration from development.ini
*** Starting uWSGI 1.2.3 (64bit) on [Tue May 29 14:43:21 2012] ***
compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 May 2012
14:28:04
detected number of CPU cores: 4
current working directory: /mnt/iscsi/appro-3-20gb/sites-root/doggy/
uwsgi/test/env/myproject
detected binary path: /mnt/iscsi/appro-3-20gb/sites-root/doggy/uwsgi/
test/env/bin/uwsgi
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 0.0.0.0:8080 fd 3
Python version: 2.6.6 (r266:84292, Dec  7 2011, 20:48:22)  [GCC 4.4.6
20110731 (Red Hat 4.4.6-3)]
Set PythonHome to /sites-root/doggy/uwsgi/test/env
*** Python threads support is disabled. You can enable it with --
enable-threads ***
Python main interpreter initialized at 0x21f29e0
your server socket listen backlog is limited to 100 connections
*** Operational MODE: preforking ***
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 22553)
spawned uWSGI worker 1 (pid: 22554, cores: 1)
spawned uWSGI worker 2 (pid: 22555, cores: 1)
spawned uWSGI worker 3 (pid: 22556, cores: 1)
spawned uWSGI worker 4 (pid: 22557, cores: 1)

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi emperor mode and pyramid

[Roberto De Ioris]

 Hello!
 When i try to run my pyramid application with uwsgi in emperor mode,
 in browser i have error:

 uWSGI Error
 Python application not found

 When i run without --emperor all works good.


 Here is detail trouble description:
 in my virtualenv i do:

 bin/easy_install pyramid
 bin/easy_install uwsgi
 bin/pcreate -t starter myproject
 cd myproject/
 ../bin/python setup.py develop

 in development.ini a add this lines
 [uwsgi]
 virtualenv = /sites-root/doggy/uwsgi/test/env
 http-socket = 0.0.0.0:8080
 master = true
 processes = 4

 when i run
 ../bin/uwsgi --ini-paste development.ini
 all works good, in browser i see demo application

 when i run
 ../bin/uwsgi --master --emperor development.ini
 in browser i see uWSGI Error Python application not found


 *** Starting uWSGI 1.2.3 (64bit) on [Tue May 29 14:43:20 2012] ***
 compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 May 2012
 14:28:04
 detected number of CPU cores: 4
 current working directory: /mnt/iscsi/appro-3-20gb/sites-root/doggy/
 uwsgi/test/env/myproject
 detected binary path: /mnt/iscsi/appro-3-20gb/sites-root/doggy/uwsgi/
 test/env/bin/uwsgi
 your memory page size is 4096 bytes
 detected max file descriptor number: 1024
 lock engine: pthread robust mutexes
 *** starting uWSGI Emperor ***
 Python version: 2.6.6 (r266:84292, Dec  7 2011, 20:48:22)  [GCC 4.4.6
 20110731 (Red Hat 4.4.6-3)]
 *** Python threads support is disabled. You can enable it with --
 enable-threads ***
 Python main interpreter initialized at 0xb5bfe0
 *** Operational MODE: no-workers ***
 spawned uWSGI master process (pid: 22551)
 *** has_emperor mode detected (fd: 5) ***
 [uWSGI] getting INI configuration from development.ini
 *** Starting uWSGI 1.2.3 (64bit) on [Tue May 29 14:43:21 2012] ***
 compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 May 2012
 14:28:04
 detected number of CPU cores: 4
 current working directory: /mnt/iscsi/appro-3-20gb/sites-root/doggy/
 uwsgi/test/env/myproject
 detected binary path: /mnt/iscsi/appro-3-20gb/sites-root/doggy/uwsgi/
 test/env/bin/uwsgi
 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 0.0.0.0:8080 fd 3
 Python version: 2.6.6 (r266:84292, Dec  7 2011, 20:48:22)  [GCC 4.4.6
 20110731 (Red Hat 4.4.6-3)]
 Set PythonHome to /sites-root/doggy/uwsgi/test/env
 *** Python threads support is disabled. You can enable it with --
 enable-threads ***
 Python main interpreter initialized at 0x21f29e0
 your server socket listen backlog is limited to 100 connections
 *** Operational MODE: preforking ***
 *** no app loaded. going in full dynamic mode ***
 *** uWSGI is running in multiple interpreter mode ***
 spawned uWSGI master process (pid: 22553)
 spawned uWSGI worker 1 (pid: 22554, cores: 1)
 spawned uWSGI worker 2 (pid: 22555, cores: 1)
 spawned uWSGI worker 3 (pid: 22556, cores: 1)
 spawned uWSGI worker 4 (pid: 22557, cores: 1)

 --

That is becasue --ini-paste is a shortcut you cannot use in the emperor
(it works only with plain config files, in your case it will use --ini
instead of --ini-paste).

Just add in your vassal config:

paste = config:%p

Internally it will be expanded as

paste = config:absolute_project_path/development.ini

(obviously you can use both forms)

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

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pyramid, threads and uWSGI

[Vlad K.]

On 01/15/2012 01:08 AM, Igor wrote:

On 14 янв, 19:11, Vlad K.v...@haronmedia.com  wrote:

Hi all!

I'm testdriving uwsgi to deploy Pyramid apps, and there's something I
don't think I quite understand.

If you want to use threads just for serving many pyramid apps in
single uwsgi process, you should probably use uwsgi's 'Emperor Mode',
it launches multiple uwsgi processes for every python app.
http://projects.unbit.it/uwsgi/wiki/Emperor



Yes, thanks, but I'm having only one application per process anyway.


V

--
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Pyramid, threads and uWSGI

[Vlad K.]

Hi all!

I'm testdriving uwsgi to deploy Pyramid apps, and there's something I 
don't think I quite understand.


First of all, I find its ability to run Pyramid natively through 
paste.deploy (via --paster option) excellent as it removes the need for 
.wsgi interface module. With that, Pyramid just works out of the box.


Now, the problem I'm having is correctly understanding how threads 
relate to uwsgi. I understand Python threads are not translated directly 
to OS threads, there's GIL so basically there is always ONE stream of 
code running at the same time per process, even with multiple CPUs.


With that in mind, my reasoning is simple: use X processes to provide 
real concurrency, and within each process have Y (GIL'ed) threads that 
will further boost the concurrency on iowaits (database interaction, 
etc...). Finding optimal X and Y is what I'm now doing for my setup.


Using uWSGI option --threads seems to launch actual OS threads within 
the process (as observed by htop) which was not my intention and then 
I'm not really sure how it works internally. Using --single-interpreter 
does not change anything, and the docs say it means Python's multiple 
interpreters (multiple isolated apps per process) concept will not be 
used, which is what I think I need.


I am still trying to understand 100% Python's concept of multiple 
interpreters and how it all fits to threads and processes with mod_wsgi.


Can you guys help me understand this deployment (with uWSGI), and 
whether my reasoning of X processes + Y Python threads as explained 
above is on track?



Thanks.


--

.oO V Oo.

--
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pyramid, threads and uWSGI

[Roberto De Ioris]

 First of all, I find its ability to run Pyramid natively through
 paste.deploy (via --paster option) excellent as it removes the need for
 .wsgi interface module. With that, Pyramid just works out of the box.

 Now, the problem I'm having is correctly understanding how threads
 relate to uwsgi. I understand Python threads are not translated directly
 to OS threads, there's GIL so basically there is always ONE stream of
 code running at the same time per process, even with multiple CPUs.

Python threads ARE mapped 1:1 to os threads. The GIL is only a pthread_mutex
governing object access (obviously, i am speaking about a pthread-based
implementation, that is the case for Linux/BSD/Solaris)


 With that in mind, my reasoning is simple: use X processes to provide
 real concurrency, and within each process have Y (GIL'ed) threads that
 will further boost the concurrency on iowaits (database interaction,
 etc...).


this is a good (and right) analysys



 Using uWSGI option --threads seems to launch actual OS threads within
 the process (as observed by htop) which was not my intention and then
 I'm not really sure how it works internally. Using --single-interpreter
 does not change anything, and the docs say it means Python's multiple
 interpreters (multiple isolated apps per process) concept will not be
 used, which is what I think I need.


if you do not intend to run multiple pyramid apps in the same process, you
can add --single-interpreter to gain a bit of memory (not performance)



 I am still trying to understand 100% Python's concept of multiple
 interpreters and how it all fits to threads and processes with mod_wsgi.

starting from uWSGI 1.0, the threading model is the same of mod_wsgi
(thanks to Graham Dumpleton help)


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

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pyramid, threads and uWSGI

[Vlad K.]

Hi, thanks for your reply.



Python threads ARE mapped 1:1 to os threads. The GIL is only a pthread_mutex
governing object access (obviously, i am speaking about a pthread-based
implementation, that is the case for Linux/BSD/Solaris)


My understanding was wrong then, but what you say makes sense.



if you do not intend to run multiple pyramid apps in the same process, you
can add --single-interpreter to gain a bit of memory (not performance)


Memory is exactly what I was concerned with. Am I correct when I say 
that single process will consume all the memory required to import all 
the used modules, but threads will all share those modules and only 
consume as much additional RAM as required by thread-local data?





Thanks,


V

--
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pyramid, threads and uWSGI

[Roberto De Ioris]

s sense.


 if you do not intend to run multiple pyramid apps in the same process,
 you
 can add --single-interpreter to gain a bit of memory (not performance)

 Memory is exactly what I was concerned with. Am I correct when I say
 that single process will consume all the memory required to import all
 the used modules, but threads will all share those modules and only
 consume as much additional RAM as required by thread-local data?


yes (more or less, there is additional memory, as stack that is allocated
for each thread, but it is very little).


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

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pyramid, threads and uWSGI

[Igor]

On 14 янв, 19:11, Vlad K. v...@haronmedia.com wrote:
 Hi all!

 I'm testdriving uwsgi to deploy Pyramid apps, and there's something I
 don't think I quite understand.

If you want to use threads just for serving many pyramid apps in
single uwsgi process, you should probably use uwsgi's 'Emperor Mode',
it launches multiple uwsgi processes for every python app.
http://projects.unbit.it/uwsgi/wiki/Emperor

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

It seem that I would be just fine to just remove the read file code. Then
nginx will take over the static file by serving the file provided in
the X-Accel-Redirect header.

#location configuration in nginx.conf

location ^~ /resources/  {
internal;
root /path/to/myapp;
}

--
# __init__.py

#add route for static files with permissions
config.add_route('resource_file', '/MyFiles/{filename}')
config.add_view(view='myapp.views.resource_file',
 route_name='resource_file',
 permission='special')

--

# myapp.views

import os
from pyramid.response import Response

def resource_file(request):
_here = os.path.dirname(__file__)
file_name = request.matchdict['filename']
response = Response(content_type='application/pdf',
 headers={'X-Accel-Redirect':'/resources/'+file_name},
body=pdf_file)
return response

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

Anyway, below are the codes. Feel free to take and modify it if you think it
can be include in the cookbook. By the way, I put status code as 200. It can
be changed anyway. As has been put just now, provide the header of
X-Accel-Redirect
header containing the static file location,  nginx will take over to serve
the static file. It was the ignorance of me to put the body before.  TQ.

#file are located in /resources
#eg to open /resources/sample.pdf -
http://www.mysite.com/MyFiles/sample.pdf

#location configuration in nginx.conf
location ^~ /resources/  {
internal;
root /path/to/myapp;
 }


--
# __init__.py

#add route for static files with permissions
config.add_route('resource_file', '/MyFiles/{filename}')
config.add_view(view='myapp.views.resource_file',
route_name='resource_file',
permission='special')

--

# myapp.views

import os
from pyramid.response import Response

def resource_file(request):
_here = os.path.dirname(__file__)
filename = request.matchdict['filename']
response= Response(content_type='application/pdf',
headers={'X-Accel-Redirect':'/resources/'+filename})
response.status='200 OK'
return response

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

Finally able to directly serve static files with permission using nginx.
Thanks Michael for your suggestion.
Just want to share my approach below:


#location configuration in nginx.conf

location ^~ /resources/  {
internal;
root /path/to/myapp;
}

--
# __init__.py

#add route for static files with permissions
config.add_route('resource_file', '/MyFiles/{filename}')
config.add_view(view='myapp.views.resource_file',
route_name='resource_file',
permission='special')

--

# myapp.views

import os
from pyramid.response import Response

def resource_file(request):
_here = os.path.dirname(__file__)
file_name = request.matchdict['filename']
pdf_file = open(os.path.join(_here, 'resources',file_name)).read()
response = Response(content_type='application/pdf',
headers={'X-Accel-Redirect':'/resources/'+file_name},
body=pdf_file)
return response

On Sun, Oct 9, 2011 at 12:55 PM, Sharil Shafie sisha...@gmail.com wrote:

 ops. The #internal was actually be uncommented. I commented it as temporary
 measure.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Michael Merickel]

Your solution actually isn't any more efficient than what you had before, so
I'd expect you'd see a similar performance issue.

The point of X-Accel-Redirect is that you do not have to open the file and
read it in Python. Your view should return a simple Response object with no
body, and just the appropriate headers (possibly content-type, as well as
status_code). nginx will see that header and add the body to the response
for you outside of Python, leaving your app free to service other requests
while nginx handles the file I/O.

If you're able to make these improvements and it works, I'd like to add this
to the Pyramid cookbook. So hopefully either you can issue a pull request to
the cookbook or just paste your changes here and I'll write it up. :-)

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

OK.  That means that the response doesnt contain that read file code. I'll
think about it. Btw, I am quite slow in this kind of thing. I am not really
a programmer. Just a math lecturer with a hobby. Hopefully I'll find a way
to improve it as suggested.


On Tue, Oct 11, 2011 at 3:05 AM, Michael Merickel mmeri...@gmail.comwrote:

 Your solution actually isn't any more efficient than what you had before,
 so I'd expect you'd see a similar performance issue.

 The point of X-Accel-Redirect is that you do not have to open the file and
 read it in Python. Your view should return a simple Response object with no
 body, and just the appropriate headers (possibly content-type, as well as
 status_code). nginx will see that header and add the body to the response
 for you outside of Python, leaving your app free to service other requests
 while nginx handles the file I/O.

 If you're able to make these improvements and it works, I'd like to add
 this to the Pyramid cookbook. So hopefully either you can issue a pull
 request to the cookbook or just paste your changes here and I'll write it
 up. :-)

 --

 Michael

 --
 You received this message because you are subscribed to the Google Groups
 pylons-discuss group.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-discuss+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-discuss?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Michael Merickel]

On Mon, Oct 10, 2011 at 2:34 PM, Sharil Shafie sisha...@gmail.com wrote:


 OK.  That means that the response doesnt contain that read file code.


That's the idea. The response body would be filled in by nginx.

Regardless this was all just a suggestion, there are other reasons why your
original response may be having issues when served directly by Pyramid. For
example, there could be misconfigured timeouts or size limitations, but it's
hard to say. Pyramid should have no trouble serving up static files under
light-moderate load. It's just that serving a file takes time, and during
that time your application won't be able to service many other requests
because it'll occupy one of the threads in your WSGI server's threadpool.

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Serving Static File with Permissions using Nginx, Uwsgi

[Boyi]

HI,
I use pyramid, uwsgi with nginx. Before this, I serve my static pdf
files using nginx. The files can be download fast. But now, because I
set the permission for the files to a directory called '/resources'
for a certain group of users by using add_static_view, my
understanding is the file will now be serve by uwsgi instead of
directly by nginx server. The '/static' directory will now only serve
js, css and template files.

The problem that I faced now is that, when users try to download the
pdf file now, the download process will stuck at certain time, and
sometimes, will stop prematurely. Even if the download complete, it
will take  a long time even when the file is small.

my nginx.conf and uwsgi parameter are as below. There should be
something wrong with my configurations. Can somebody bring some light
to solve my probs?

TQ.


#nginx.conf
user  user user;
worker_processes  2;

events {
worker_connections  1024;
 }

http {
include   mime.types;
default_type  application/octet-stream;


sendfileon;
#tcp_nopush on;

keepalive_timeout  65;

server {
listen 80;
server_name myweb.com;
access_log /path/to/directory/file.log;
error_log /path/to/log/debug/file.log debug;
charset utf-8;
root /path/to/my/app;
#index  Home index.html index.htm;

location /static  {
  root /path/to/my/app;
  expires max;
}

#for robot.txt and favicon
location ~* \.(txt|ico)$ {
root /path/to/my/app/static/directory;
expires max;
}

location / {
nclude uwsgi_params;
uwsgi_pass unix:/tmp/uwsgi.sock;
#uwsgi_param SCRIPT_NAME /;
}
}

}

--
my uwsgi parameter:
socket = /tmp/uwsgi.sock
home = /my/home/path
daemonize = /path/to/log/uwsgi.log

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Graham Higgins]

Dunno if it's relevant but you have a typo in the posted config at least:

location / { 
nclude uwsgi_params; 


-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/ID2ey966l28J.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

Not relevant unfortunately. That's pasting error.

On 08-Oct-2011 10:19 PM, Graham Higgins gjhigg...@gmail.com wrote:

Dunno if it's relevant but you have a typo in the posted config at least:

location / {
nclude uwsgi_params;



-- 
You received this message because you are subscribed to the Google Groups
pylons-discuss gro...
To view this discussion on the web visit
https://groups.google.com/d/msg/pylons-discuss/-/ID2ey966l28J.


To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this grou...

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Michael Merickel]

You can still have nginx serve your static files after pyramid has checked
the permissions by having pyramid return a response containing the
x-accel-redirect header. For more info about it look into nginx's version of
X-Sendfile.

http://wiki.nginx.org/X-accel
http://wiki.nginx.org/XSendfile

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

I did follow your suggestions. The files in the directory and its sub
directories will be served. I did go along well with the permission stuff.
But the problem still persist. If I try to open the pdf through google
chrome, if the download stuck, it will stuck forever even if i reload. It
would stuck at the same byte size. The pdf file wont be displayed. I think
it's something wrong with  uwsgi or nginx config but cant figure out why. I
might be some something to do with the my system resources. I didnt get this
problem if I use paster.

location /resources/~*  {
#internal;
root /root/to/app;
expires max;
}

On Sun, Oct 9, 2011 at 1:10 AM, Michael Merickel mmeri...@gmail.com wrote:

 You can still have nginx serve your static files after pyramid has checked
 the permissions by having pyramid return a response containing the
 x-accel-redirect header. For more info about it look into nginx's version of
 X-Sendfile.

 http://wiki.nginx.org/X-accel
 http://wiki.nginx.org/XSendfile

 --

 Michael

  --
 You received this message because you are subscribed to the Google Groups
 pylons-discuss group.

 To post to this group, send email to pylons-discuss@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-discuss+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-discuss?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Serving Static File with Permissions using Nginx, Uwsgi

[Sharil Shafie]

ops. The #internal was actually be uncommented. I commented it as temporary
measure.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: gzipmiddleware and http://projects.unbit.it/uwsgi

[writeson]

Roberto,

Thanks for the reply. I agree, I should be serving static files (*.js,
*.css, etc.) from the webserver, I guess I don't know how to do that;
get Apache2 (what we're using) to serve up the files from the /public
folder inside my Pylons project. Got any pointers, or does this fall
under the Web Serving 101?

The rest of this response is the contents of the gzip middleware I
mentioned. This is taken almost verbatim from The Definitive Guide to
Pylons book.

import gzip
import StringIO

class GzipMiddleware(object):
'''This class implements gzip compression for *.js and *.css files
delivered by the pylons applications'''
def __init__(self, app, compresslevel=9):
self.app = app
self.compresslevel = compresslevel

def __call__(self, environ, start_response):
if 'gzip' not in environ.get(HTTP_ACCEPT_ENCODING, ):
return self.app(environ, start_response)

if environ[PATH_INFO][-3:] != .js and environ[PATH_INFO]
[-4:] != .css:
return self.app(environ, start_response)

buffer = StringIO.StringIO()
output = gzip.GzipFile(
mode=wb,
compresslevel=self.compresslevel,
fileobj=buffer
)
start_response_args = []
def dummy_start_response(status, headers, exc_info=None):
start_response_args.append(status)
start_response_args.append(headers)
start_response_args.append(exc_info)
return output.write

app_iter = self.app(environ, dummy_start_response)
for line in app_iter:
output.write(line)

if hasattr(app_iter, close):
app_iter.close()

output.close()
buffer.seek(0)
result = buffer.getvalue()
headers = []
for name, value in start_response_args[1]:
if name.lower() != content-length:
headers.append((name, value))
headers.append((Content-Length, str(len(result
headers.append((Content-Encoding, gzip))
start_response(start_response_args[0], headers,
start_response_args[2])
buffer.close()
return [result]

On Sep 20, 10:18 am, Roberto De Ioris robe...@unbit.it wrote:
 Il giorno 20/set/2010, alle ore 16.02, writeson ha scritto:





  Hi all,
  I've been building some Pylons web applications for our Intranet.
  These are deployed using a standalone uwsgi server (http://
  projects.unbit.it/uwsgi), which seems to work well, except for one
  issue. I've incorporated the GzipMiddleware.py code shown in the
  Pylons book into my config/middleware.py code. This works great when
  run with paster, but when my application is deployed under uwsgi the
  files that are supposed to get gzipped (*.css, *.js) are reporting
  back:

  NS_ERROR_INVALID_CONTENT_ENCODING

  in HttpFox. Does anyone have any ideas, suggestions or pointers that
  might help me out? My applications use quite a few jQuery plugin files
  as well as jQuery UI css files, so I'd like to compress these if I
  can.

 Why are you serving those files via uWSGI ?

 You should serve static files via the webserver, it is the right tool for the 
 job.

 (obviously if they are dinamically generated ignore my response)

 By the way, could you post this GzipMiddleware.py so i can check it ?

 Thanks

 --
 Roberto De Iorishttp://unbit.it
 JID: robe...@jabber.unbit.it

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[cd34]

Talking direct to uwsgi requires a python helper as Graham mentions.
While I do like the nginx/uwsgi stack, I don't have any problems with
apache/mod_wsgi.  Both are very capable and I find that apache/
mod_wsgi is probably easier to set up and has a much larger support/
installed base. I've deployed applications using both.  In terms of
stability, neither architecture has had any real issues.  In terms of
performance, nginx has a large edge on static files and for this
particular project, that was necessary.  I haven't found the server -
wsgi - pylons gateway to be significantly better or worse in either
scenario.

http://www.reddit.com/r/Python/comments/be1q1/benchmark_of_python_web_servers/

is a discussion of the benchmark site listed above with quite a
venomous discussion.

As a personal recommendation, I typically would push someone in the
Apache/mod_wsgi direction, but, there are reasons to chose competing
solutions based on the full stack management.  While it may add
somewhat to the support burden, choosing a solution that isn't widely
deployed will sometimes cause issues.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

uwsgi pylons redirect_to problem

[Weixi Yen]

I'm really stuck on this one.

My stack is nginx  uwsgi  pylons.

There is a point of failure between uwsgi  pylons where if I use
redirect_to on a controller, the app throws a 302 error.

It works in paste, but not uwsgi.

Any pointers would be greatly appreciated.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

uwsgi

[Mike Orr]

On Tue, Aug 10, 2010 at 2:42 AM, Weixi Yen weixi...@gmail.com wrote:
 My stack is nginx  uwsgi  pylons.

I haven't heard of uWSGI before so I assume a lot of Pylons users
haven't either. From the website (http://projects.unbit.it/uwsgi/) it
looks like a mod_wsgi equivalent plus a lot of other stuff. Who here
is using it and how do you like it?

I run my apps under Supervisor with http proxy, mainly so that I can
stop and restart them individually (supervisor restart app1). Does
uWSGI allow this?

-- 
Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[weixi...@gmail.com]

I picked uwsgi b/c it seemed like potentially less overhead coupled
with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
that the newer stable versions of nginx comes with uwsgi integration
by default, you just need to install uwsgi to get started.

I've not using supervisor but it's super easy to start the uwsgi
daemon:
uwsgi --uid www-data --paste config:/location/to/your/production.ini --
socket :8080 -d /var/log/uwsgi.log

cd34 was the one that mentioned it and I was prompted to look into
it.

This article has benchmarks:
http://nichol.as/benchmark-of-python-web-servers

I used this article as a reference:
http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/

It works just like mod_wsgi except a lot simpler as you don't need to
apache config files.



On Aug 10, 10:16 am, Mike Orr sluggos...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 2:42 AM, Weixi Yen weixi...@gmail.com wrote:
  My stack is nginx  uwsgi  pylons.

 I haven't heard of uWSGI before so I assume a lot of Pylons users
 haven't either. From the website (http://projects.unbit.it/uwsgi/) it
 looks like a mod_wsgi equivalent plus a lot of other stuff. Who here
 is using it and how do you like it?

 I run my apps under Supervisor with http proxy, mainly so that I can
 stop and restart them individually (supervisor restart app1). Does
 uWSGI allow this?

 --
 Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Mike Orr]

On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com wrote:
 I picked uwsgi b/c it seemed like potentially less overhead coupled
 with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
 that the newer stable versions of nginx comes with uwsgi integration
 by default, you just need to install uwsgi to get started.

 I've not using supervisor but it's super easy to start the uwsgi
 daemon:
 uwsgi --uid www-data --paste config:/location/to/your/production.ini --
 socket :8080 -d /var/log/uwsgi.log

So you have a separate uwsgi daemon for each application, rather than
one for all the applications? In that case, the uwsgi command line
itself could run under Supervisor.

-- 
Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[weixi...@gmail.com]

Yup.

I think I'm going to use supervisor too now.  Seems easier to manage
than the /etc/init.d scripts.


On Aug 10, 12:23 pm, Mike Orr sluggos...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com 
 wrote:
  I picked uwsgi b/c it seemed like potentially less overhead coupled
  with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
  that the newer stable versions of nginx comes with uwsgi integration
  by default, you just need to install uwsgi to get started.

  I've not using supervisor but it's super easy to start the uwsgi
  daemon:
  uwsgi --uid www-data --paste config:/location/to/your/production.ini --
  socket :8080 -d /var/log/uwsgi.log

 So you have a separate uwsgi daemon for each application, rather than
 one for all the applications? In that case, the uwsgi command line
 itself could run under Supervisor.

 --
 Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Mike Orr]

So essentially, uWSGI works like SCGI? I.e., you have your daemon
running on some port, and a separate Apache/etc module contacts it.
So is there a simple client somewhere for testing your site with a
URL without a webserver? That's another reason I've been proxying, so
that I can use a text browser on the server to check whether the
application itself is not responding or Apache is not passing it
through right.

On Tue, Aug 10, 2010 at 1:42 PM, weixi...@gmail.com weixi...@gmail.com wrote:
 Yup.

 I think I'm going to use supervisor too now.  Seems easier to manage
 than the /etc/init.d scripts.


 On Aug 10, 12:23 pm, Mike Orr sluggos...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com 
 wrote:
  I picked uwsgi b/c it seemed like potentially less overhead coupled
  with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
  that the newer stable versions of nginx comes with uwsgi integration
  by default, you just need to install uwsgi to get started.

  I've not using supervisor but it's super easy to start the uwsgi
  daemon:
  uwsgi --uid www-data --paste config:/location/to/your/production.ini --
  socket :8080 -d /var/log/uwsgi.log

 So you have a separate uwsgi daemon for each application, rather than
 one for all the applications? In that case, the uwsgi command line
 itself could run under Supervisor.

 --
 Mike Orr sluggos...@gmail.com

 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To post to this group, send email to pylons-disc...@googlegroups.com.
 To unsubscribe from this group, send email to 
 pylons-discuss+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/pylons-discuss?hl=en.





-- 
Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[cd34]

uwsgi runs as a daemon, and nginx talks to it.  uwsgi does some rather
aggressive caching which makes for a very fast pylons app.

If I recall, I had problems with versions newer than 0.9.4.4, but,
haven't tried any later releases.  The command line I use is:

/usr/src/uwsgi-0.9.4.4/uwsgi -d /tmp/uwsgi.log --uid 1000 --gid 1000 -
s /tmp/uwsgi.sock -C -iH /var/www/facebook/ --paste config:/var/www/
facebook/fbapp/production.ini

And my application handles /

The question is, what is redirecting incorrectly?

I strip off /static/ and /fb/ and allow nginx to serve those:


location ^~ /static/ {
alias   /var/www/xx.com/static/;
}
location ^~ /fb/ {
alias   /var/www/xx.com/fb/;
}
location / {
uwsgi_pass  unix:/tmp/uwsgi.sock;
include uwsgi_params;
}

and I believe I added:

uwsgi_param  SCRIPT_NAME/;

in uwsgi_params.

http://cd34.com/blog/programming/python/pylons-and-facebook-application-layout/
and
http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/

detail it a bit more.

I didn't have any problems using redirect_to which was used in a few
places.  Based on your description, it is possible SCRIPT_NAME is
missing which would give you urls like:  
http://domain.com/physical/disk/path/controller/action

If you can run something like livehttpheaders in firefox, or, even
something as basic as telnetting to nginx's port and doing a request
to see what the Location: header is, it might be a little easier to
troubleshoot it.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Graham Dumpleton]

On Aug 11, 3:16 am, Mike Orr sluggos...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 2:42 AM, Weixi Yen weixi...@gmail.com wrote:
  My stack is nginx  uwsgi  pylons.

 I haven't heard of uWSGI before so I assume a lot of Pylons users
 haven't either. From the website (http://projects.unbit.it/uwsgi/) it
 looks like a mod_wsgi equivalent plus a lot of other stuff.

It may appear to have a lot of stuff, but uWSGI is actually less
capable than Apache/mod_wsgi in various ways.

The difference is that Apache/mod_wsgi doesn't have a marketing page
hyping what it does in the same way uWSGI does. :-(

Graham

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Graham Dumpleton]

On Aug 11, 3:48 am, weixi...@gmail.com weixi...@gmail.com wrote:
 I picked uwsgi b/c it seemed like potentially less overhead coupled
 with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
 that the newer stable versions of nginx comes with uwsgi integration
 by default, you just need to install uwsgi to get started.

 I've not using supervisor but it's super easy to start the uwsgi
 daemon:
 uwsgi --uid www-data --paste config:/location/to/your/production.ini --
 socket :8080 -d /var/log/uwsgi.log

 cd34 was the one that mentioned it and I was prompted to look into
 it.

 This article has benchmarks:http://nichol.as/benchmark-of-python-web-servers

Just be aware that this benchmark used a flawed configuration for
Apache/mod_wsgi. Specifically they setup Apache with 1000 threads in
the process. One would never actually do this in practice. All they
achieved by doing that was give the impression that Apache used a lot
more memory that uWSGI. They would have likely got same performance
results for Apache/mod_wsgi with just a handful of threads and if same
number used as uWSGI was using, memory usage should have been quite
comparable.

Graham

 I used this article as a 
 reference:http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/

 It works just like mod_wsgi except a lot simpler as you don't need to
 apache config files.

 On Aug 10, 10:16 am, Mike Orr sluggos...@gmail.com wrote:



  On Tue, Aug 10, 2010 at 2:42 AM, Weixi Yen weixi...@gmail.com wrote:
   My stack is nginx  uwsgi  pylons.

  I haven't heard of uWSGI before so I assume a lot of Pylons users
  haven't either. From the website (http://projects.unbit.it/uwsgi/) it
  looks like a mod_wsgi equivalent plus a lot of other stuff. Who here
  is using it and how do you like it?

  I run my apps under Supervisor with http proxy, mainly so that I can
  stop and restart them individually (supervisor restart app1). Does
  uWSGI allow this?

  --
  Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Graham Dumpleton]

On Aug 11, 5:23 am, Mike Orr sluggos...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com 
 wrote:
  I picked uwsgi b/c it seemed like potentially less overhead coupled
  with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
  that the newer stable versions of nginx comes with uwsgi integration
  by default, you just need to install uwsgi to get started.

  I've not using supervisor but it's super easy to start the uwsgi
  daemon:
  uwsgi --uid www-data --paste config:/location/to/your/production.ini --
  socket :8080 -d /var/log/uwsgi.log

 So you have a separate uwsgi daemon for each application,

Which you can also do with Apache/mod_wsgi.

Graham

 rather than
 one for all the applications? In that case, the uwsgi command line
 itself could run under Supervisor.

 --
 Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Weixi Yen]

Thanks, turns out the SCRIPT_NAME /; is handled incorrectly.

Running liveheaders, it appears that when redirect_to is used, then the
request gets served as http://controller/action without the domain.

I think it's appending / to another / to cause a double //

No idea of a workaround though =/


On Tue, Aug 10, 2010 at 3:26 PM, cd34 mcd...@gmail.com wrote:

 uwsgi runs as a daemon, and nginx talks to it.  uwsgi does some rather
 aggressive caching which makes for a very fast pylons app.

 If I recall, I had problems with versions newer than 0.9.4.4, but,
 haven't tried any later releases.  The command line I use is:

 /usr/src/uwsgi-0.9.4.4/uwsgi -d /tmp/uwsgi.log --uid 1000 --gid 1000 -
 s /tmp/uwsgi.sock -C -iH /var/www/facebook/ --paste config:/var/www/
 facebook/fbapp/production.ini

 And my application handles /

 The question is, what is redirecting incorrectly?

 I strip off /static/ and /fb/ and allow nginx to serve those:


location ^~ /static/ {
alias   /var/www/xx.com/static/;
}
location ^~ /fb/ {
alias   /var/www/xx.com/fb/;
}
location / {
uwsgi_pass  unix:/tmp/uwsgi.sock;
include uwsgi_params;
}

 and I believe I added:

 uwsgi_param  SCRIPT_NAME/;

 in uwsgi_params.


 http://cd34.com/blog/programming/python/pylons-and-facebook-application-layout/
 and
 http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/

 detail it a bit more.

 I didn't have any problems using redirect_to which was used in a few
 places.  Based on your description, it is possible SCRIPT_NAME is
 missing which would give you urls like:
 http://domain.com/physical/disk/path/controller/action

 If you can run something like livehttpheaders in firefox, or, even
 something as basic as telnetting to nginx's port and doing a request
 to see what the Location: header is, it might be a little easier to
 troubleshoot it.

 --
 You received this message because you are subscribed to the Google Groups
 pylons-discuss group.
 To post to this group, send email to pylons-disc...@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/pylons-discuss?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Weixi Yen]

Ah found the solution:
http://lists.unbit.it/pipermail/uwsgi/2010-July/000484.html

On Tue, Aug 10, 2010 at 6:01 PM, Weixi Yen weixi...@gmail.com wrote:

 Thanks, turns out the SCRIPT_NAME /; is handled incorrectly.

 Running liveheaders, it appears that when redirect_to is used, then the
 request gets served as http://controller/action without the domain.

 I think it's appending / to another / to cause a double //

 No idea of a workaround though =/



 On Tue, Aug 10, 2010 at 3:26 PM, cd34 mcd...@gmail.com wrote:

 uwsgi runs as a daemon, and nginx talks to it.  uwsgi does some rather
 aggressive caching which makes for a very fast pylons app.

 If I recall, I had problems with versions newer than 0.9.4.4, but,
 haven't tried any later releases.  The command line I use is:

 /usr/src/uwsgi-0.9.4.4/uwsgi -d /tmp/uwsgi.log --uid 1000 --gid 1000 -
 s /tmp/uwsgi.sock -C -iH /var/www/facebook/ --paste config:/var/www/
 facebook/fbapp/production.ini

 And my application handles /

 The question is, what is redirecting incorrectly?

 I strip off /static/ and /fb/ and allow nginx to serve those:


location ^~ /static/ {
alias   /var/www/xx.com/static/;
}
location ^~ /fb/ {
alias   /var/www/xx.com/fb/;
}
location / {
uwsgi_pass  unix:/tmp/uwsgi.sock;
include uwsgi_params;
}

 and I believe I added:

 uwsgi_param  SCRIPT_NAME/;

 in uwsgi_params.


 http://cd34.com/blog/programming/python/pylons-and-facebook-application-layout/
 and
 http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/

 detail it a bit more.

 I didn't have any problems using redirect_to which was used in a few
 places.  Based on your description, it is possible SCRIPT_NAME is
 missing which would give you urls like:
 http://domain.com/physical/disk/path/controller/action

 If you can run something like livehttpheaders in firefox, or, even
 something as basic as telnetting to nginx's port and doing a request
 to see what the Location: header is, it might be a little easier to
 troubleshoot it.

 --
 You received this message because you are subscribed to the Google Groups
 pylons-discuss group.
 To post to this group, send email to pylons-disc...@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/pylons-discuss?hl=en.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Graham Dumpleton]

On Aug 11, 11:01 am, Weixi Yen weixi...@gmail.com wrote:
 Thanks, turns out the SCRIPT_NAME /; is handled incorrectly.

 Running liveheaders, it appears that when redirect_to is used, then the
 request gets served ashttp://controller/actionwithout the domain.

 I think it's appending / to another / to cause a double //

 No idea of a workaround though =/

Not surprising really. This is because WSGI specification dictates
that SCRIPT_NAME shouldn't ever be ''/' by itself.

For URL against root of site, should be:

  SCRIPT_NAME =
  PATH_INFO = /

The PATH_INFO must always have a leading '/' and thus why for root of
site, SCRIPT_NAME would end up being empty.

So, try using:

  uwsgi_param  SCRIPT_NAME;

Graham


 On Tue, Aug 10, 2010 at 3:26 PM, cd34 mcd...@gmail.com wrote:
  uwsgi runs as a daemon, and nginx talks to it.  uwsgi does some rather
  aggressive caching which makes for a very fast pylons app.

  If I recall, I had problems with versions newer than 0.9.4.4, but,
  haven't tried any later releases.  The command line I use is:

  /usr/src/uwsgi-0.9.4.4/uwsgi -d /tmp/uwsgi.log --uid 1000 --gid 1000 -
  s /tmp/uwsgi.sock -C -iH /var/www/facebook/ --paste config:/var/www/
  facebook/fbapp/production.ini

  And my application handles /

  The question is, what is redirecting incorrectly?

  I strip off /static/ and /fb/ and allow nginx to serve those:

     location ^~ /static/ {
         alias   /var/www/xx.com/static/;
     }
     location ^~ /fb/ {
         alias   /var/www/xx.com/fb/;
     }
     location / {
         uwsgi_pass  unix:/tmp/uwsgi.sock;
         include     uwsgi_params;
     }

  and I believe I added:

  uwsgi_param  SCRIPT_NAME        /;

  in uwsgi_params.

 http://cd34.com/blog/programming/python/pylons-and-facebook-applicati...
  and
 http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/

  detail it a bit more.

  I didn't have any problems using redirect_to which was used in a few
  places.  Based on your description, it is possible SCRIPT_NAME is
  missing which would give you urls like:
 http://domain.com/physical/disk/path/controller/action

  If you can run something like livehttpheaders in firefox, or, even
  something as basic as telnetting to nginx's port and doing a request
  to see what the Location: header is, it might be a little easier to
  troubleshoot it.

  --
  You received this message because you are subscribed to the Google Groups
  pylons-discuss group.
  To post to this group, send email to pylons-disc...@googlegroups.com.
  To unsubscribe from this group, send email to
  pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@go 
  oglegroups.com
  .
  For more options, visit this group at
 http://groups.google.com/group/pylons-discuss?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Weixi Yen]

That worked perfectly for me, thanks :)

On Tue, Aug 10, 2010 at 6:24 PM, Graham Dumpleton 
graham.dumple...@gmail.com wrote:



 On Aug 11, 11:01 am, Weixi Yen weixi...@gmail.com wrote:
  Thanks, turns out the SCRIPT_NAME /; is handled incorrectly.
 
  Running liveheaders, it appears that when redirect_to is used, then the
  request gets served ashttp://controller/actionwithout the domain.
 
  I think it's appending / to another / to cause a double //
 
  No idea of a workaround though =/

 Not surprising really. This is because WSGI specification dictates
 that SCRIPT_NAME shouldn't ever be ''/' by itself.

 For URL against root of site, should be:

  SCRIPT_NAME =
  PATH_INFO = /

 The PATH_INFO must always have a leading '/' and thus why for root of
 site, SCRIPT_NAME would end up being empty.

 So, try using:

  uwsgi_param  SCRIPT_NAME;

 Graham

 
  On Tue, Aug 10, 2010 at 3:26 PM, cd34 mcd...@gmail.com wrote:
   uwsgi runs as a daemon, and nginx talks to it.  uwsgi does some rather
   aggressive caching which makes for a very fast pylons app.
 
   If I recall, I had problems with versions newer than 0.9.4.4, but,
   haven't tried any later releases.  The command line I use is:
 
   /usr/src/uwsgi-0.9.4.4/uwsgi -d /tmp/uwsgi.log --uid 1000 --gid 1000 -
   s /tmp/uwsgi.sock -C -iH /var/www/facebook/ --paste config:/var/www/
   facebook/fbapp/production.ini
 
   And my application handles /
 
   The question is, what is redirecting incorrectly?
 
   I strip off /static/ and /fb/ and allow nginx to serve those:
 
  location ^~ /static/ {
  alias   /var/www/xx.com/static/;
  }
  location ^~ /fb/ {
  alias   /var/www/xx.com/fb/;
  }
  location / {
  uwsgi_pass  unix:/tmp/uwsgi.sock;
  include uwsgi_params;
  }
 
   and I believe I added:
 
   uwsgi_param  SCRIPT_NAME/;
 
   in uwsgi_params.
 
  http://cd34.com/blog/programming/python/pylons-and-facebook-applicati.
 ..
   and
  http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/
 
   detail it a bit more.
 
   I didn't have any problems using redirect_to which was used in a few
   places.  Based on your description, it is possible SCRIPT_NAME is
   missing which would give you urls like:
  http://domain.com/physical/disk/path/controller/action
 
   If you can run something like livehttpheaders in firefox, or, even
   something as basic as telnetting to nginx's port and doing a request
   to see what the Location: header is, it might be a little easier to
   troubleshoot it.
 
   --
   You received this message because you are subscribed to the Google
 Groups
   pylons-discuss group.
   To post to this group, send email to pylons-disc...@googlegroups.com.
   To unsubscribe from this group, send email to
   pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com
 pylons-discuss%2bunsubscr...@go oglegroups.com
   .
   For more options, visit this group at
  http://groups.google.com/group/pylons-discuss?hl=en.

 --
 You received this message because you are subscribed to the Google Groups
 pylons-discuss group.
 To post to this group, send email to pylons-disc...@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/pylons-discuss?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Noah Gift]

On Tue, Aug 10, 2010 at 4:49 PM, Graham Dumpleton
graham.dumple...@gmail.com wrote:


 On Aug 11, 5:23 am, Mike Orr sluggos...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com 
 wrote:
  I picked uwsgi b/c it seemed like potentially less overhead coupled
  with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
  that the newer stable versions of nginx comes with uwsgi integration
  by default, you just need to install uwsgi to get started.

  I've not using supervisor but it's super easy to start the uwsgi
  daemon:
  uwsgi --uid www-data --paste config:/location/to/your/production.ini --
  socket :8080 -d /var/log/uwsgi.log

 So you have a separate uwsgi daemon for each application,

 Which you can also do with Apache/mod_wsgi.


I have used mod_wsgi with Apache a lot and I like it.  On the other
hand, nginx is a pretty cool web server.  Any thought to combining
efforts on making a unified module, that shares some of the same code,
for both platforms?  I could see situations where I would want to use
Apache and other situations where I would want nginx.  I think they
are both good to have around.







 Graham

 rather than
 one for all the applications? In that case, the uwsgi command line
 itself could run under Supervisor.

 --
 Mike Orr sluggos...@gmail.com

 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To post to this group, send email to pylons-disc...@googlegroups.com.
 To unsubscribe from this group, send email to 
 pylons-discuss+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/pylons-discuss?hl=en.





-- 
Thanks,

Noah

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Graham Dumpleton]

On Aug 11, 1:02 pm, Noah Gift noah.g...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 4:49 PM, Graham Dumpleton





 graham.dumple...@gmail.com wrote:

  On Aug 11, 5:23 am, Mike Orr sluggos...@gmail.com wrote:
  On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com 
  wrote:
   I picked uwsgi b/c it seemed like potentially less overhead coupled
   with nginx, rather than nginx  apache mod_wsgi.   My reasoning was
   that the newer stable versions of nginx comes with uwsgi integration
   by default, you just need to install uwsgi to get started.

   I've not using supervisor but it's super easy to start the uwsgi
   daemon:
   uwsgi --uid www-data --paste config:/location/to/your/production.ini --
   socket :8080 -d /var/log/uwsgi.log

  So you have a separate uwsgi daemon for each application,

  Which you can also do with Apache/mod_wsgi.

 I have used mod_wsgi with Apache a lot and I like it.  On the other
 hand, nginx is a pretty cool web server.  Any thought to combining
 efforts on making a unified module, that shares some of the same code,
 for both platforms?  I could see situations where I would want to use
 Apache and other situations where I would want nginx.  I think they
 are both good to have around.

I have pondered that for mod_wsgid. That is mod_wsgi without embedded
mode, but now having its own process manager (supervisor). Technically
the daemon infrastructure, even though written against Apache runtime
library could be used as back end to nginx in similar style to uWSGI,
but retaining various features mod_wsgi has which uWSGI doesn't.

I will not disagree that nginx from everything I know is better for
static file handling, and also the behaviour of mod_proxy in nginx
when used as a front end to Apache/mod_wsgi allows Apache to work more
efficiently for dynamic web application with less resources than if no
front end. Ie., due to nginx acting as network buffer and isolating
Apache from slow clients.

This model of nginx proxying to Apache/mod_wsgi does as some point out
though mean having to manage multiple servers, so the daemon
infrastructure of mod_wsgi directly behind nginx is attractive,
presuming that mod_proxy's good qualities in nginx can be harnessed in
that arrangement as well.

Why am I not doing this though. The prime reason is lack of time. When
I can find myself a better job, maybe I'll get that opportunity time
wise to pursue it.

This does though presume I can get the motivation up as well.

The joke used to be that every man and his dog was writing a Python
web framework, now it is that every man and his dog is writing a WSGI
hosting mechanism. With the rash of options around, one has to
question whether yet another variation is going to be accepted or not.

A further issue is trying to support multiple servers. Right now I am
happy with supporting just Apache because it means I can do a top
class job with it and ensure that it works perfectly. When you support
multiple servers, you have to spread your time more across all the
options and quality potentially drops. This may be fine for the uWSGI
folks who get to do the work as part of their paid day job and have
customers potentially paying them for support as well, but I don't
have that luxury.

All the same, would be interested to here if people think that
supporting other servers would be good, or whether felt that uWSGI,
and Phusion Passenger, is already satisfying that space now and so no
point.

Graham


  rather than
  one for all the applications? In that case, the uwsgi command line
  itself could run under Supervisor.

  --
  Mike Orr sluggos...@gmail.com

  --
  You received this message because you are subscribed to the Google Groups 
  pylons-discuss group.
  To post to this group, send email to pylons-disc...@googlegroups.com.
  To unsubscribe from this group, send email to 
  pylons-discuss+unsubscr...@googlegroups.com.
  For more options, visit this group 
  athttp://groups.google.com/group/pylons-discuss?hl=en.

 --
 Thanks,

 Noah

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: uwsgi

[Mike Orr]

So, how again do you test a uwsgi-daemon or mod_wsgi daemon site? With
PasteHTTPServer I can just fire up a text browser and send it an HTTP
request. But what's kind of client can form a uWSGI or SCGI request?
It's not rare that I upgrade an app and restart it and it refuses to
start and Apache won't tell me why, the Supervisor log is empty and
there's nothing useful in the app error log. Sometimes I can run it in
development mode and see what the problem is, but other times it needs
the exact production environment; e.g., for a permission error where
my account can write a file but the www-data can't, or where it can't
open a log file because the directory containing it doesn't exist. So
a command-line client or browser plugin that can take a URL and send a
uWSGI or SCGI request would seem like a vital tool for troubleshooting
such installations, yet it doesn't seem to exist.

-- 
Mike Orr sluggos...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.