routing to a log file when daemonizing a fastcgi process

[tamas kemenczy]

Hi all,

Recently at work I've encountered a need to be able to redirect the
stdout/stderr of a daemonized fastcgi Django process to a log file
(something other than /dev/null). Django has a nice daemonizing
function django.utils.daemon.become_daemon, which takes arguments for
out_log and err_log, however the
django.core.servers.fastcgi.runfastcgi function, which makes use of
become_daemon, only specifies the our_home_dir argument, so it doesn't
seem like the other arguments of become_daemon are being utilized. For
example, runfastcgi could take two additional options, something like
outlog and errlog, which could be passed to become_daemon. Then one
could specify log files to write to via manage.py runfcgi.

I looked to see if there was any discussion or related tickets but
found none. I have a patch that enables the above if this is relevant
to the Django community, but has this been considered already and if
not, would it merit a ticket?

Best,
Tamas Kemenczy

[Jacob Kaplan-Moss]

On 2/29/08, tamas kemenczy <tkem...@gmail.com> wrote:
> I looked to see if there was any discussion or related tickets but
> found none. I have a patch that enables the above if this is relevant
> to the Django community, but has this been considered already and if
> not, would it merit a ticket?

Yeah, go ahead and file a ticket with the patch -- seems like an
obvious oversight on our part.

Jacob

[jedie]

On 29 Feb., 21:38, tamas kemenczy <tkemen...@gmail.com> wrote:
> Recently at work I've encountered a need to be able to redirect the
> stdout/stderr of a daemonized fastcgi Django process to a log file
> (something other than /dev/null).

This is very interesting for me, too. Can you post you existing code
in a django ticket?

btw. i have problems to setup a fastCGI app in a non root environment.
If something is not right, it only helps to look into the Apache error
log. But i haven't access to the log file :(
Sometimes it helps to activate the flup "low level" debug traceback,
but this is deactivated hardcoded with http://code.djangoproject.com/changeset/4170
I have created a patch for this:

http://code.djangoproject.com/ticket/6610


Redirect stdout/stderr into a file helps, too. I created a fastCGI
dispatcher on the top of the django runfastcgi() function. In this
additional layer i implemented a file logging (using the logging
module) and a way for catching all possible errors and displayed these
with a small own WSGI app. These two files contains the code:

http://pylucid.net:8080/pylucid/browser/trunk/pylucid/index.fcgi
http://pylucid.net:8080/pylucid/browser/trunk/pylucid/PyLucid/system/fastcgi_server.py

Unfortunately, not all errors intercepted :( It would help, if there
exist something like a "always reload" mode in tb_catch_app(), but i
don't know to implement this.


--
Mfg.

Jens Diemer


----
A django powered CMS: http://www.pylucid.org

[tamas kemenczy]

On Mar 4, 2:36 am, jedie <google.gro...@jensdiemer.de> wrote:
> This is very interesting for me, too. Can you post you existing code
> in a django ticket?

i have created a ticket with the patch here:

http://code.djangoproject.com/ticket/6687

tamas