On Aug 11, 2010, at 8:21 AM, mdipierro wrote: > We could have a standard web2py logging file such as errors.log
I think that would be a good default, but I'd rather have a standard web2py logging configuration file, web2py/logging.conf or the like. It could point to errors.log by default, but the user could edit the configuration file to change that. The logging module also supports rotating log files, which would be a good default, I think, to prevent runaway log file growth. I was just looking at the RHEL init startup scripts (this applies to Fedora as well); when web2py is started that way (which is what I do in production), stdout and stderr are automatically redirected to /dev/null (in the daemon function), so redirection in the startup script will be overridden. I'd like Tim's input on this, since Rocket has some logging initialization logic as well. Tim: the subject is consistent (and configurable) runtime logging for the web2py core as well as applications. > > On Aug 11, 10:14 am, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Aug 11, 2010, at 6:00 AM, mdipierro wrote: >> >>> we could specify line option to change it but why not use regular >>> stdout redirection? >> >> I suppose we could, but at least when we start via web2py.py, it's good to >> see the startup messages directed to stdout before web2py daemonizes. >> >> The nice thing about having a standard logging configuration file is that it >> gives the user a lot more control over things. For example, if I understand >> the logging module correctly, it could be used to send logging to syslog. >> >> A question, though: web2py can run in various deployment modes. I'm >> wondering if there's a central place to configure logging, common to all >> modes? >> >> rocket does installs logging.NullHandler, for example. I'm unclear on the >> implications of that for web2py applications. >> >> >> >>> On Aug 10, 12:28 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >>>> web2py makes semi-extensive use of the Python logging module, but (near as >>>> I can tell) it never changes the output away from the default stdout. >> >>>> Is this true, and if so isn't it a problem?
