Debugging and inspecting¶
The highly asynchronous nature of
larigira might lead to difficulty in
larigira has some features to help you with debugging.
First of all, you might want to run larigira with the environment variable
LARIGIRA_DEBUG set to
env LARIGIRA_DEBUG=true larigira
With this on, message logging is much more verbose. Please observe that log messages provide information about the logger name from which the message originated: this is typically the class name of the object.
larigira also provides HTTP API to help you with debug:
/api/debug/running, for example, provides detailed information about
running greenlets, with several representations:
audiogensobject will contain informations about greenlets associated with scheduled events. Here you can see its
timespec, and many other details
greenletsobject provides a simple list of every greenlets. Associated with every greenlet there is as much information as possible: object name, documentation, etc.
greenlets_treehas the same information as
greenlets, but is shown as a tree: this is often easier to understand. For example, the
Controllergreenlet should have three children (
A user-friendly, but more limited, visualization is available at
larigira receives the
ALRM signal, three things happen: the playlist
length is checked (as if
CHECK_SECS passed); the event system “ticks” (as
EVENT_TICK_SECS passed); the DB is reloaded from disk.
This is useful if you want to debug the event system, or if you manually
changed the data on disk. Please note that the event system will automatically
reload the DB from disk when appropriate. However, the WebUI will not, so you
might have a misleading
/db/list page; send an
ALRM in this case.
The same effect can be triggered performing an HTTP