Turn off logging?

Hi guys,

I'm still stuck on the broken pipe error I reported ( http://tinyurl.com/3cl3un
) back in March, it's driving me completely insane.

One thing I would like to try would be to turn off logging,
since the
exception seems to originate in the logging module, but I
can't figure
out how to. This page: http://cherrypy.org/
wiki/Logging shows me that
I can set log.screen to false to turn off stdout logging,
but how can
I turn off (or just be sure they're off) log.access_file
and
log.error_file?

-Bill Mill
bill.millgmail.com

PS Here are some things I have tried:

* changing many template engine settings
* rewriting all of my template files and changing template
engine
(Cheetah -> Mako)
* installing a local python 2.5 instead of using my web
host's python
(2.4.1 -> 2.5.1)
* removing all logging statements from my code

Obviously, none of them have helped. I'm still accepting any
ideas.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

OK, turning off screen logging seems to have stopped the
error. Does
anybody have any idea why leaving screen logging on with
cherrypy
2.2.1 does not cause errors while leaving it on with 3.0.1
causes
consistent crashes?

-Bill Mill
bill.mill at gmail.com
http://billmill.org

On May 5, 12:15 am, Bill  Mill <bill.m...gmail.com> wrote:
> Hi guys,
>
> I'm still stuck on the broken pipe error I reported (http://tinyurl.com/3cl3un
> ) back in March, it's driving me completely insane.
>
> One thing I would like to try would be to turn off
logging, since the
> exception seems to originate in the logging module, but
I can't figure
> out how to. This page:http://cherrypy
.org/wiki/Loggingshows me that
> I can set log.screen to false to turn off stdout
logging, but how can
> I turn off (or just be sure they're off)
log.access_file and
> log.error_file?
>
> -Bill Mill
> bill.m...gmail.com
>
> PS Here are some things I have tried:
>
> * changing many template engine settings
> * rewriting all of my template files and changing
template engine
> (Cheetah -> Mako)
> * installing a local python 2.5 instead of using my web
host's python
> (2.4.1 -> 2.5.1)
> * removing all logging statements from my code
>
> Obviously, none of them have helped. I'm still
accepting any ideas.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On May 5, 7:48 am, Bill  Mill <bill.m...gmail.com> wrote:
> OK, turning off screen logging seems to have stopped
the error. Does
> anybody have any idea why leaving screen logging on
with cherrypy
> 2.2.1 does not cause errors while leaving it on with
3.0.1 causes
> consistent crashes?

Looking over your original error again, it seems like
there's an
initial log message, then an error while trying to log that
message to
stdout, then the broken pipe error while trying to log
*that* to
stderr. Unfortunately, I don't know of any way for CP to
"look before
you leap" to see if stdout/stderr are valid.

[In CP 2.x, screen logging was performed via
"print" statements. If
something went wrong with it, there was no further attempt
to log
anything; the exception was just propagated out.]

Are you starting the CP process on its own, or are you using
Apache to
start it [1]? If the latter, it's understandable that stdout
and
stderr would be closed or otherwise unavailable. Just leave
"log.screen" off and you should be OK. If you're
starting the CP
process yourself, it's up to you to determine whether and
how you keep
a terminal connected to it or not.

Yet another reason CP 3.1 needs a more unified deployment
approach. :/


Robert Brewer
System Architect
Amor Ministries
fumanchuamor.org

[1] For example, using the "autostart.cgi" module
as described at
http://tool
s.cherrypy.org/wiki/ModRewrite


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On May 5, 1:10 pm, fumanchu <fuman...amor.org> wrote:
> On May 5, 7:48 am, Bill  Mill <bill.m...gmail.com> wrote:
>
> > OK, turning off screen logging seems to have
stopped the error. Does
> > anybody have any idea why leaving screen logging
on with cherrypy
> > 2.2.1 does not cause errors while leaving it on
with 3.0.1 causes
> > consistent crashes?
>
> Looking over your original error again, it seems like
there's an
> initial log message, then an error while trying to log
that message to
> stdout, then the broken pipe error while trying to log
*that* to
> stderr. Unfortunately, I don't know of any way for CP
to "look before
> you leap" to see if stdout/stderr are valid.
>

Yup, agreed, I can't believe I didn't investigate the
logging more
thoroughly before last night. I guess I just assumed I was
at fault
somehow :|

> [In CP 2.x, screen logging was performed via
"print" statements. If
> something went wrong with it, there was no further
attempt to log
> anything; the exception was just propagated out.]
>

Makes sense.

> Are you starting the CP process on its own, or are you
using Apache to
> start it [1]? If the latter, it's understandable that
stdout and
> stderr would be closed or otherwise unavailable. Just
leave
> "log.screen" off and you should be OK. If
you're starting the CP
> process yourself, it's up to you to determine whether
and how you keep
> a terminal connected to it or not.

That's exactly what happened; I was using a cgi I wrote
myself so that
Apache would fire up the cp server. The weird part is that
it took
finally fail; 25-30 minutes, in my experiments last night.

>
> Yet another reason CP 3.1 needs a more unified
deployment approach. :/

Concur. Perhaps we can add a warning to the Logging wiki
page and the
Apache deployment page about this error? I'd like to
contribute some
documentation, may I have a password to edit the wiki?

>
> [1] For example, using the "autostart.cgi"
module as described at http://tool
s.cherrypy.org/wiki/ModRewrite

That's almost exactly the script I'm using (but I think by
coincidence? Who knows, I wrote it a long time ago).

-Bill Mill
bill.mill at gmail.com
http://billmill.org


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On May 6, 3:55 am, Bill  Mill <bill.m...gmail.com> wrote:
> On May 5, 1:10 pm, fumanchu <fuman...amor.org> wrote:
> > Are you starting the CP process on its own, or are
you using Apache to
> > start it [1]? If the latter, it's understandable
that stdout and
> > stderr would be closed or otherwise unavailable.
Just leave
> > "log.screen" off and you should be OK.
If you're starting the CP
> > process yourself, it's up to you to determine
whether and how you keep
> > a terminal connected to it or not.
>
> That's exactly what happened; I was using a cgi I wrote
myself so that
> Apache would fire up the cp server. The weird part is
that it took
> finally fail; 25-30 minutes, in my experiments last
night.
>
> > Yet another reason CP 3.1 needs a more unified
deployment approach. :/
>
> Concur. Perhaps we can add a warning to the Logging
wiki page and the
> Apache deployment page about this error? I'd like to
contribute some
> documentation, may I have a password to edit the wiki?

In general, writing to sys.stdout will be a problem with CGI
scripts
run under Apache as standard output is how a response is
communicated
back to the Apache server. Thus, any direct attempts to
write to
sys.stdout will actually interfere with that and corrupt the
response
or in the worst case confuse Apache, which is possibly what
you were
seeing. There should not be a problem with writing to
sys.stderr
within a CGI script with output being routed back to the
Apache error
log.

In respect of starting up a separate CherryPy server from a
CGI
script, it would probably be wise to be re associating
standard in/out/
error to something completely different else they will
remain attached
to the Apache process. By just starting up the CherryPy
server using:

import os
os.setpgid(os.getpid(), 0)
os.system('/usr/local/bin/python2.4 webserver.py &')

this will not happen and thus why anything written to
standard output
from CherryPy server would be a problem. I would thus
perhaps suggest
that the recipe for starting up a CherryPy server actually
be:

import os
os.setpgid(os.getpid(), 0)
os.system('/usr/local/bin/python2.4 webserver.py <
/dev/null > /some/
path/file.log 2>&1 &')

As an aside, because CherryPy now supports the idea of being
hosted on
top of any WSGI adapter, it should be noted that a portable
WSGI
application component should never write to sys.stdout
directly or
indirectly using 'print'. This is because different WSGI
adapters,
such as those for CGI, may use  both sys.stdin and
sys.stdout as a
communication mechanism for talking to a web server. The
WSGI
specification though doesn't say anything in respect of
stuff outside
of the core interface specification. Thus, there is nothing
to say
that a WSGI adapter should be hiding the original values for
sys.stdin
and sys.stdout, and replacing them with an empty stream and
sys.stderr
accordingly. In other words, you simply can't rely on
sys.stdin and
sys.stdout being usable in a WSGI hosted application.

I know Robert is aware of this issue from discussions
previously on
Python WEB-SIG list, but not sure how future versions of
CherryPy may
deal with this.

Graham


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On May 6, 3:01 pm, Graham Dumpleton <Graham.Dumple...gmail.com>
wrote:
> In respect of starting up a separate CherryPy server
from a CGI
> script, it would probably be wise to be re associating
standard in/out/
> error to something completely different else they will
remain attached
> to the Apache process. By just starting up the CherryPy
server using:
>
> import os
> os.setpgid(os.getpid(), 0)
> os.system('/usr/local/bin/python2.4 webserver.py
&')
>
> this will not happen and thus why anything written to
standard output
> from CherryPy server would be a problem. I would thus
perhaps suggest
> that the recipe for starting up a CherryPy server
actually be:
>
> import os
> os.setpgid(os.getpid(), 0)
> os.system('/usr/local/bin/python2.4 webserver.py <
/dev/null > /some/
> path/file.log 2>&1 &')

You might also get away with:

import os
os.setpgid(os.getpid(), 0)
os.system('/usr/local/bin/python2.4 webserver.py <
/dev/null 1>&2 &')

This will mean that standard output gets routed on standard
error and
thus to Apache error log.

Do note though that such output may not appear in Apache
error log
unless Python sys.stderr and sys.stdout are flushed
explicitly. I know
this is an issue in mod_python, but not sure what happens
with stuff
executed under CGI.

Graham


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---