##// END OF EJS Templates
hg: Redirect Mercurial stdout/stderr to logging when running as WSGI...
hg: Redirect Mercurial stdout/stderr to logging when running as WSGI Any "console" output from Mercurial when Kallithea is running from WSGI should end up in Kallithea's logs. That seems like a nice general feature. This will however also solve another rare but more critical problem: Mercurial is writing to sys.stdout / sys.stderr, using several layers of wrapping. Since Mercurial 5.5 (with https://repo.mercurial-scm.org/hg/rev/8e04607023e5 ), all writes are given a memoryview. Apache httpd mod_wsgi is invoking the WSGI with a custom mod_wsgi.Log injected in sys.stdout / sys.stderr . This logger can however not handle memoryview - https://github.com/GrahamDumpleton/mod_wsgi/issues/863 .

File last commit:

r5817:87ac42db default
r8795:fe050a93 stable
Show More
debugging.rst
33 lines | 1.2 KiB | text/x-rst | RstLexer

Debugging Kallithea

If you encounter problems with Kallithea, here are some instructions on how to debug them.

Note

First make sure you're using the latest version available.

Enable detailed debug

Kallithea uses the standard Python logging module to log its output. By default only loggers with INFO level are displayed. To enable full output change level = DEBUG for all logging handlers in the currently used .ini file. This change will allow you to see much more detailed output in the log file or console. This generally helps a lot to track issues.

Enable interactive debug mode

To enable interactive debug mode simply comment out set debug = false in the .ini file. This will trigger an interactive debugger each time there is an error in the browser, or send a http link if an error occurred in the backend. This is a great tool for fast debugging as you get a handy Python console right in the web view.

Warning

NEVER ENABLE THIS ON PRODUCTION! The interactive console can be a serious security threat to your system.