Support #18977

turn down fileAction severity

Added by Raymond Culbertson over 2 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


In mu2e art exe's we always get two severe errors:

MessageLogger Summary
type category sev module subroutine count total
---- -------------------- -- ---------------- ---------------- ----- -----
1 fileAction -s PostEndRun 1 1
2 fileAction -s PostProcessEvent 1 1

I think these are being generated by file open and close messages, which
are logged to "absolute" category which is severity "severe". Since
there are no actual errors, it seems these should not be reported
as severe. Can this be changed to "verbatim" category with severity "info"?
Or is there a reason it is done this way? Thanks


#1 Updated by Kyle Knoepfel over 2 years ago

  • Status changed from New to Feedback

What you propose makes sense, however it will require a stakeholder discussion since that informational message is intended to emitted upon every file open and close.

#2 Updated by Raymond Culbertson over 2 years ago

Thanks. If I understand, it seems to align with what I noticed, that
it would be helpful to have "info" "important info" "really important info".
There are information messages we want to promote over other informational
messages. For example, we want to log the path to the config files and
make it hard for the user to turn that message off, harder than
average "info" messages. We also wanted the art heartbeat to stay on
even if we turn off other info messages. Without this feature we
can only suppress info by the category string. This has the downside
of suppressing warnings of the same category. This will happen in the
art "RANDOM" category. If we want to stop info "instantiating HepJames Engine"
then we also suppress warnings in the RANDOM category, I think. (This
could also be fixed by using more categories like RANDOM_INIT_ENGINE and
RANDOM_BADSTATE, etc. which can then be suppressed individually.
In my amateur observation of MF, this seems to be the intended style.)

#3 Updated by Kyle Knoepfel over 2 years ago

We will discuss your request with the stakeholders to lower the severity of those logged messages. The "INFO", "IMPORTANT INFO" request should be a feature request, where we are able to discuss a sensible design that meets the needs of Mu2e (and other experiments).

#4 Updated by Kyle Knoepfel over 2 years ago

  • Status changed from Feedback to Assigned

Also available in: Atom PDF