Debugging and inspecting ============================ The highly asynchronous nature of ``larigira`` might lead to difficulty in debugging. However, ``larigira`` has some features to help you with debugging. Debugging options ----------------- First of all, you might want to run larigira with the environment variable ``LARIGIRA_DEBUG`` set to ``true``. ``env LARIGIRA_DEBUG=true larigira`` will do. 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. Debug API --------- ``larigira`` also provides HTTP API to help you with debug: ``/api/debug/running``, for example, provides detailed information about running greenlets, with several representations: * the ``audiogens`` object will contain informations about greenlets associated with *scheduled* events. Here you can see its ``audiospec``, ``timespec``, and many other details * the ``greenlets`` object provides a simple list of every greenlets. Associated with every greenlet there is as much information as possible: object name, documentation, etc. * the ``greenlets_tree`` has the same information as ``greenlets``, but is shown as a tree: this is often easier to understand. For example, the ``Controller`` greenlet should have three children (``MpcWatcher``, ``Timer`` and ``Monitor``). A user-friendly, but more limited, visualization is available at ``/view/status/running`` Signals --------- When ``larigira`` receives the ``ALRM`` signal, three things happen: the playlist length is checked (as if ``CHECK_SECS`` passed); the event system "ticks" (as if ``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.