[erlang-questions] Prevent my crashing gen_server to produce any error message

Frank Muller frank.muller.erl@REDACTED
Wed Sep 12 16:44:17 CEST 2018


You made my day Siri. Working perfectly now and I’m able to suppress all
reports from certain type of processes.

The examples you provided should be added to the official doc.

Thanks again!!!

/Frank

There are several different types of reports for a crashing process:
>
> 1) for gen* behaviours (gen_server, gen_event, gen_statem, ...), you get
> an error report issued by the crashing process just before it dies. For a
> gen_server, these messages start with " ** Generic server <...>
> terminating". These can be silenced with the process metadata + filter I
> suggested in my previous mail.
>
> 2) for gen* behaviours and other processes started with proc_lib, you get
> a crash report issued from the crashing process just before it dies. These
> reports (by default) have the heading == CRASH REPORT==, and the message
> starts with "crasher: ". These can be silenced with the process metadata +
> filter I suggested in my previous mail.
>
> 3) If the crashed process was part of a supervisor tree, a supervisor
> report is issued from the process' parent, that is, its supervisor. These
> reports (by default) have the heading == SUPERVISOR REPORT ==, and the
> message contains "errorContext: child_terminated". Since they are issued
> from a different process, these are not silenced by the suggested filter.
>
> 4) If the crashed process is not a gen* behaviour, and it is not started
> by proc_lib, then the emulator issues an error report which starts with
> "Error in process <...> with exit value:". These are not silenced by the
> suggested filter.
>
> These are the ones I can think of right now - and I assume that what you
> see are the supervisor reports only. Is this correct?
>
> How to silence the supervisor report depends on what you want to see from
> other processes. You can turn off supervisor reports with errorContext
> child_terminated completely for your system with this filter:
>
> logger:add_primary_filter(stop_sup_reports,{fun(#{log:=#{label:={supervisor,child_terminated}}},_)
> -> stop; (_,_) -> ignore end, ok}).
>
> or for one specific supervisor (fah_sup) with this one:
>
> logger:add_primary_filter(stop_sup_reports,{fun(#{msg:={report,#{label:={supervisor,child_terminated},report:=R}}},_)
> -> case proplists:get_value(supervisor,R) of {local,fah_sup} -> stop; _ ->
> ignore end; (_,_) -> ignore end, ok}).
>
> If the supervisor has other types of children, you might want to silence
> the reports related to one specific child id (fah) only. Then you can use
> this filter:
>
> logger:add_primary_filter(stop_sup_reports,{fun(#{msg:={report,#{label:={supervisor,child_terminated},report:=R}}},_)
> -> Child = proplists:get_value(offender,R), case
> proplists:get_value(id,Child) of fah -> stop; _ -> ignore end; (_,_) ->
> ignore end, ok}).
>
> Since I don't know much about what your system does and needs, these are
> only a few ideas. Another possibility can be to turn off all so called
> "SASL reports" completely - this would silence reports 2) and 3) for all of
> your system - if that is acceptable.
>
> The pid-idea from my first mail would only be needed for the emulator
> logs, 4) in my listing above, which I don't believe you see?
>
>
>
>>> Maybe this:
>>>
>>> logger:add_primary_filter(my_filter_id,{fun(#{meta:=#{label:={proc_lib,crash}}})
>>> -> stop; (_,_) -> ignore end,ok}).
>>>
>>> ?
>>>
>>>
> I assume Len meant to put 'msg' instead of 'meta' here. That would work,
> but it would silence the crash reports, 2) in my listing above, from all
> processes, not only the specific ones.
>
> I hope this is of some help!
> Kind Regards
> /siri
>
>
>>>
> ---
>>> Led
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180912/fd41bd32/attachment.htm>


More information about the erlang-questions mailing list