Ticket Navigation

Ticket #646 (defect)

Opened 2 years ago

Last modified 1 year ago

logging breaks when running as daemon

Status: closed (toolfix)

Reported by:	walter AT livinglogic DOT de	Assigned to:	rdelon
Priority:	normal	Milestone:	3.0
Component:	CherryPy code	Keywords:
Cc:

I'm trying to run my CherryPy server as a daemon process (using ll.daemon available from http://www.livinglogic.de/Python/daemon/). With CherryPy 2.2.1 this worked flawlessly. 3.0 however is giving me problems. Here is a small test script that demonstrates the bug:

import os

import cherrypy

from ll import daemon

cherrypy.config.update(
	{
		"server.environment": "production",
		"server.socket_port": 9999,
		"server.thread_pool": 10,
		"server.log_to_screen": 0,
		"server.log_file": "/home/walter/cherrylogs/wiki.error",
		"server.log_access_file": "/home/walter/cherrylogs/wiki.access",
	}
)


if __name__ == "__main__":
	d = daemon.Daemon(
		pidfile="/var/run/walter/wiki.pid",
		user="walter",
		group="users",
	)
	if d.service():
		cherrypy.quickstart(lambda n: "foo", "/")

Here is the stacktrace I'm getting:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.5/logging/__init__.py", line 1351, in shutdown
    h.flush()
  File "/usr/local/lib/python2.5/logging/__init__.py", line 731, in flush
    self.stream.flush()
ValueError: I/O operation on closed file
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.5/logging/__init__.py", line 1351, in shutdown
    h.flush()
  File "/usr/local/lib/python2.5/logging/__init__.py", line 731, in flush
    self.stream.flush()
ValueError: I/O operation on closed file
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.5/logging/__init__.py", line 1351, in shutdown
    h.flush()
  File "/usr/local/lib/python2.5/logging/__init__.py", line 731, in flush
    self.stream.flush()
ValueError: I/O operation on closed file
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.5/logging/__init__.py", line 1351, in shutdown
    h.flush()
  File "/usr/local/lib/python2.5/logging/__init__.py", line 731, in flush
    self.stream.flush()
ValueError: I/O operation on closed file

Change History

01/17/07 16:27:55: Modified by fumanchu

Hm. To start, the config keys for logging have changed. Your example should read:

cherrypy.config.update(
        {
                "environment": "production",
                "server.socket_port": 9999,
                "server.thread_pool": 10,
                "log.screen": False,
                "log.error_file": "/home/walter/cherrylogs/wiki.error",
                "log.access_file": "/home/walter/cherrylogs/wiki.access",
        }
)

Second, I don't understand why you're passing a function to cherrypy.quickstart(lambda n: "foo", "/"). You should pass a Root instance (that has page handlers as methods) or an instance of cherrypy.Application if you want more control.

01/18/07 06:50:55: Modified by walter AT livinglogic DOT de

OK, I've changed the logging configuration according to your example. However this doesn't change the traceback.

I've used a lambda in the quickstart() call simply for demonstration purposes. The real code of course uses a root instance with handler methods.

01/29/07 23:51:08: Modified by fumanchu

Hm. Looks like you're seeing a similar problem to this recently patched bug on Python SF. Since the fix for that delves into main.c, asking you to patch that is a bit much. Python 2.5 has a new global logging.raiseExceptions attribute that you can set to False to just silence these errors, but that will silence more than just shutdown errors. :/ Maybe you can set it to False in an engine stop callback?

02/01/07 04:12:47: Modified by walter AT livinglogic DOT de

I've applied Python SVN revision r53250 to my local version of Python 2.5 and recompiled. However this does not fix the problem (still the same stack trace). I now added logging.raiseExceptions = False to the start of the script and with this the server runs fine. How would the engine stop callback version look?

02/01/07 11:49:36: Modified by fumanchu

To use an engine stop callback, instead of:

logging.raiseExceptions = False

...write something like this:

def silence_logging_errors():
    logging.raiseExceptions = False
cherrypy.engine.on_stop_engine_list.append(silence_logging_errors)

02/02/07 12:31:49: Modified by walter AT livinglogic DOT de

I tried that, but this results in the same stack trace as before. An unconditional logging.raiseExceptions = False works.

06/22/07 10:16:36: Modified by fumanchu

status changed from new to closed.
resolution set to toolfix.
milestone set to 3.0.

10/05/07 12:08:01: Modified by fumanchu

Python bug report moved to http://bugs.python.org/issue1566280.