Как всегда регистрировать / показывать причину ошибки, когда дочерний элемент супервизора возвращает ошибку из start_link?

При запуске gen_server из супервизора (который сам запускается приложением) у меня возникает проблема, когда start_link gen_server не возвращает {ok, ...}, а {error, Reason} единственное сообщение об ошибке, которое я вижу:

=INFO REPORT==== 20-Jan-2011::13:14:43 ===
    application: foo
    exited: {shutdown,{foo_app,start,[normal,[]]}}
    type: temporary

Reason для завершения не отображается / не регистрируется.

Есть ли способ увидеть / зарегистрировать эти ошибки, возвращаемые супервизору?

Я использую childspec, например:

{ok, {{one_for_one, 3, 10},  ... 
    {usb_mux_1, 
    {usb_mux, start_link, 
    [Some_Params]},
    permanent, 
    10000, 
    worker, 
    [usb_mux]}, ...

Изменить: пояснение

Я знаю об error_logger и уже пользуюсь им. Вопрос не в том, как что-то зарегистрировать, а в том, как заставить супервизора регистрировать причину его завершения, например log, кто завершил работу с возвратом ошибки, и что она вернула.

И чтобы это тоже не мешало, да, я начинаю erlang с sasl на:

 -boot start_sasl

erlang gen-server erlang-supervisor otp
person Peer Stritzinger    schedule 20.01.2011    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я только что нашел ответ:

Супервизор действительно регистрирует ошибку выхода как отчет о сбое.

Проблема в том, что оболочка не отображает эти отчеты о сбоях. Чтобы запутать меня, он показывает информацию / предупреждения и отчеты об ошибках, но не отчеты о ходе работы и отчеты о сбоях от супервизора.

Если я посмотрю в журнал на диске, там будет подробный отчет о сбое:

10> rb:show(4).

CRASH REPORT  <0.53.0>                                      2011-01-20 17:33:52
===============================================================================
Crashing process                                                               
   initial_call                                  {usb_mux,init,['Argument__1']}
   pid                                                                 <0.53.0>
   registered_name                                                           []
   error_info
         {exit,{undef,[{usb_port,get_gw_hw_spec,[<0.59.0>]},
...

Причина, по которой события SASL не отображались на экране, заключалась в пропуске в -config файле, который выглядел так:

[{sasl, [
     {sasl_error_logger, false},    %% no SASL error logger installed
     {error_logger_mf_dir,"./log"}, 
     {error_logger_mf_maxbytes,10485760}, % 10 MB
     {error_logger_mf_maxfiles, 10}
     ]}].

Это означает, что был установлен многофайловый регистратор ошибок (все записи error_logger_mf_*), но не экранный регистратор для событий SASL.

Изменение записи, как это, исправило это:

     {sasl_error_logger, tty},  %% SASL reports to tty

Из справочной страницы sasl:

sasl_report_tty_h:

Форматирует и записывает отчеты супервизора, отчеты о сбоях и отчеты о проделанной работе в stdio.

person Peer Stritzinger    schedule 20.01.2011