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

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

2 голосов
/ 20 января 2011

При запуске 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 и уже использую его. Вопрос не в том, как что-то записать в журнал, а в том, как заставить супервизора записать причину прекращения, например. лог, который завершился с ошибкой возврата и что он вернул.

И просто чтобы убрать это с пути, да, я запускаю erlang с включенным sasl: 

 -boot start_sasl

1 Ответ

3 голосов
/ 20 января 2011

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

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

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

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

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.

...