Project

General

Profile

Support #18977

turn down fileAction severity

Added by Raymond Culbertson over 1 year ago. Updated over 1 year ago.

Status:
Assigned
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
02/12/2018
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
Mu2e
SSI Package:
Co-Assignees:
Duration:

Description

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

History

#1 Updated by Kyle Knoepfel over 1 year 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 1 year 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 1 year 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 1 year ago

  • Status changed from Feedback to Assigned


Also available in: Atom PDF