[lttng-dev] Enabling and disabling events

[Thibault, Daniel]

   Suppose we do something like this (edited for brevity):

$ lttng enable-event -u sample:message --loglevel notice
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [enabled]
$ lttng disable-event -u sample:message
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
$ lttng enable-event -u sample:message
$ lttng list session
Events:
  sample:message [enabled]
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
$ lttng enable-event -u sample:message --loglevel err
$ lttng list session
Events:
  sample:message [enabled]
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
  sample:message (loglevel: TRACE_ERR (3)) [enabled]

This could be understood to mean that sample:message will be logged unless its loglevel lies in the TRACE_WARNING (4) to TRACE_NOTICE (5) range.  But that is not what lttng is doing: it looks up all the rules which match the candidate event, then ORs the results together.  (Two rules are different if their string key or loglevel setting are different; currently lttng treats a loglevel-only setting as it it matched the corresponding loglevel setting)  So in this case there is no way that sample:message could not be logged, since the first "rule" (i.e. sample:message [enabled]) trumps the others.

Wouldn't it be much clearer if the enable-event command did some clean up in the list of rules?  The previous use case would then become:

$ lttng enable-event -u sample:message --loglevel notice
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [enabled]
$ lttng disable-event -u sample:message
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
$ lttng enable-event -u sample:message
$ lttng list session
Events:
  sample:message [enabled]
$ lttng enable-event -u sample:message --loglevel err
$ lttng list session
Events:
  sample:message [enabled]

In other words, we have a partial ordering on the loglevel key that goes:
LTTNG_EVENT_LOGLEVEL_ALL > LTTNG_EVENT_LOGLEVEL_RANGE(m),
LTTNG_EVENT_LOGLEVEL_ALL > LTTNG_EVENT_LOGLEVEL_SINGLE(n),
LTTNG_EVENT_LOGLEVEL_RANGE(m) > LTTNG_EVENT_LOGLEVEL_SINGLE(n) if m>=n

It is tempting to extend the partial ordering to the text key, but I think we then need to change the interpretation of the rules from a simple "OR":

$ lttng enable-event -u "sample:mes*"
$ lttng list session
Events:
  sample:mes* [enabled]
$ lttng enable-event -u sample:message
$ lttng list session
Events:
  sample:mes* [enabled]
$ lttng disable-event -u sample:message
$ lttng list session
Events:
  sample:mes* [enabled]
  sample:message [disabled]

The user's wish of "enabling sample:mes* except for sample:message" would be achieved if the daemon treated the disabling rules as having priority over the enabling ones.  Instead of having a single list with each list entry having an enabled/disabled attribute, the daemon would need to maintain two lists, one for enabling rules, the other for disabling rules (and the list entries of both lists would be attribute-less).

This approach would dovetail nicely with the proposed exclusion special character (!).  A command like:

$ lttng enable-event -u "sample:mes*" "!sample:message"

Would readily be resolved as an entry in each list.

But then how could we deal with:

$ lttng disable-event -u "sample:mes*" "!sample:message"

(In other words, "disabling sample:mes* except for sample:message")  Maybe we'd need two sets of disabling rules: a weak one (enabling rules have priority) and a strong one (enabling rules don't have priority).  Although that could still be reasonably understandable when displayed with 'lttng list session' if the rules were presented in three ordered blocks (strong disabling rules, enabling rules, weak disabling rules), I suspect the scheme is getting too complex.

This needs more thought.   :-)

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>