touching wsgi file

[belred]

is touchingt the wsgi file supposed reload every file in the the
entire django project or just just reload the one wsgi file?

thanks,

bryan

[Graham Dumpleton]

On Nov 3, 7:09 am, belred <bel...@gmail.com> wrote:
> is touchingt the wsgi file supposed reload every file in the the
> entire django project or just just reload the one wsgi file?

If you are talking about the WSGI script file when using Apache/
mod_wsgi, it depends on how you have Apache/mod_wsgi configured. See:

http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

In other words, for whole Django instance to be reloaded you must be
using UNIX and have configured mod_wsgi daemon mode and delegated the
Django instance to run in the daemon mode process group.

Graham

[belred]

i am using linux and i am using mod_wsgi to run django.

i don't understand this sentence.

"This should only be done for daemon processes and not within the
Apache child processes"...

we have many apache child process. if i follow this code:

if environ['mod_wsgi.process_group'] != '':
import signal, os
os.kill(os.getpid(), signal.SIGINT)


will it restart django in the one child process the code executes in
or all child processes for the given django project? (i'm trying to
find a way to restart the entire django project regardless of how many
child processes are running). also doesn't the mod_wsgi daemon process
exist within an apache child process? if so, that above sentence
doesn't make sense to me. there must be something i'm missing or
don't understand because i don't see documentation or people asking
questions about properly running django on high volume sites under
apache child processes in linux. maybe this is not the recommended
way it's done.




On Nov 2, 2:17 pm, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:

[Graham Dumpleton]

On Nov 3, 9:55 am, belred <bel...@gmail.com> wrote:
> i am using linux and i am using mod_wsgi to run django.
>
> i don't understand this sentence.
>
> "This should only be done for daemon processes and not within the
> Apache child processes"...
>
> we have many apache child process.  if i follow this code:
>
> if environ['mod_wsgi.process_group'] != '':
>     import signal, os
>     os.kill(os.getpid(), signal.SIGINT)
>
> will it restart django in the one child process the code executes in
> or all child processes for the given django project?  (i'm trying to
> find a way to restart the entire django project regardless of how many
> child processes are running). also doesn't the mod_wsgi daemon process
> exist within an apache child process?  if so, that above sentence
> doesn't make sense to me.  there must be something i'm missing or
> don't understand because i don't see documentation or people asking
> questions about properly running django on high volume sites under
> apache child processes in linux.  maybe this is not the recommended
> way it's done.

Are you using mod_wsgi daemon mode or not? If you don't know, then
post how you have configured Apache for mapping to WSGI application
running under mod_wsgi.

The term 'Apache child processes' here is referring to the normal
Apache child worker process which handles all types of requests,
including static files, PHP etc etc. It doesn't say 'worker' because
then people get it confused with 'worker' MPM, thinking it perhaps
only applies to 'worker' MPM and not 'prefork' MPM as well.

When using mod_wsgi daemon mode, with requests being correctly
delegated to the daemon process for a specific application, then there
are distinct processes referred to as mod_wsgi daemon mode processes.
Technically these are also a forked child of Apache parent process,
but they only run WSGI requests proxied to it by the normal Apache
child worker processes, they DO NOT do handling of static requests,
PHP etc etc.

The reason you don't want to use the kill() code in normal Apache
child worker processes is two fold.

First is that the normal Apache child worker processes handle requests
for static files, PHP etc etc. Thus, sending a kill signal to itself
could interfere with the operation of other code for another distinct
application executing in the same process. Also, the Apache MPM being
used may interpret signals to mean different things than how a
mod_wsgi daemon mode process does and so you could break the process
is some way rather than shut it down.

The second reason is that on UNIX, Apache is generally multiprocess
and so you would only be shutting down the one process and not all
Apache child worker processes.

Even when doing this in mod_wsgi daemon mode, the daemon process group
should only have one process. This is why the documentation says:

"""To force a daemon process to be restarted, if you are using a
single daemon process with many threads for the application, then you
can embed a page in your application (password protected hopefully),
that sends an appropriate signal to itself."""

In particular, it says 'if you are using a single daemon process'. If
not using a single daemon process, you shouldn't use this technique.

If using daemon mode and have multiple processes in the daemon process
group, touching the WSGI script file will have the effect of causing
daemon mode processes for that application to be restarted the next
time a request arrives for it.

Normally one would manually touch the WSGI script file from outside of
Apache or application, by using 'touch' on the command line. One could
automate it and do it from application if you really want to:

if environ['mod_wsgi.process_group'] != '':
import os
os.utime(environ["SCRIPT_FILENAME", None)

The 'environ' variable here is the WSGI environment dictionary. The
'SCRIPT_FILENAME' attribute is an Apache specific variable which
indicates the target resource, which in this case just happens to be
the WSGI script file.

If you want code to be portable beyond mod_wsgi, this would need to be
written differently. I'll elaborate on that more later if need to.

The user that mod_wsgi daemon mode process runs as should have
permissions to allow it to update the modification time of the WSGI
script file.

Graham

[belred]

thanks for your detailed explanation. i had to read it 3 times to try
to absorb everything :) i do not need to have the code be portable
beyond mod_wsgi. if i'm following what you and steve have said and
pages you both pointed me to, it appears if i want to share global
data i really need to use daemon mode with single process and multiple
threads. to restart django under mod_wsgi using daemon mode, i just
need to touch the wsgi file. actually, i currently have code that
uses os.utime, but i didn't know about the SCRIPT_FILE environment
variable, so that's a really good tip. i was using a hard-coded path
in settings.py. i don't think it worked for me because i don't think
i'm in daemon mode. i don't have the script in front of me at this
time, so i can't share it with you now. i'm a little unclear if you
said that touching the wsgi file works only in wsgi daemon/multi-
process mode or in wsgi daemon regardless of multiprocess/
multitheaded mode. having the child processes restart on the next
request is not a problem for me, just as long at every mod-wsgi
daemon process eventually gets restarted on it's next request.

bryan

[Graham Dumpleton]

On Nov 3, 12:31 pm, belred <bel...@gmail.com> wrote:
> thanks for your detailed explanation.  i had to read it 3 times to try
> to absorb everything :) i do not need to have the code be portable
> beyond mod_wsgi.  if i'm following what you and steve have said and
> pages you both pointed me to, it appears if i want to share global
> data i really need to use daemon mode with single process and multiple
> threads.   to restart django under mod_wsgi using daemon mode, i just
> need to touch the wsgi file.  actually, i currently have code that
> uses os.utime, but i didn't know about the SCRIPT_FILE environment
> variable, so that's a really good tip.  i was using a hard-coded path
> in settings.py.  i don't think it worked for me because i don't think
> i'm in daemon mode.  i don't have the script in front of me at this
> time, so i can't share it with you now. i'm a little unclear if you
> said that touching the wsgi file works only in wsgi daemon/multi-
> process  mode or in wsgi daemon regardless of multiprocess/
> multitheaded mode.

Touching WSGI script file works for daemon mode no matter how many
processes/threads you have configured for the daemon process group.

> having the child processes restart on the next
> request is not a problem for me,  just as long at every mod-wsgi
> daemon process eventually gets restarted on it's next request.

All will be restarted before they next handle an actual request.

What tends to happen is that on next request, the daemon process to
which request was proxied says 'sorry, I need to restart'. The Apache
child worker gets this message and so closes connection to daemon
process and attempts to connect to daemon processes again. This time
another in group would pick it up and would do the same thing. In
effect you get a cascade, with all processes in daemon process group
trying to handle it and all realising they need to restart. When one
of the restarted processes finally comes back up and grabs request
again, it will handle the request.

Graham