[erlang-questions] Why I cannot start sasl from my app file application specification

[Fred Hebert]

Answers inline

On 08/15, Ivan Carmenates García wrote:
> Hi Fred,
> 
> Thanks, the best solution I came with for now is to start it manually from
> start/2 callback function, because I have the Erlang R16B and I don't have
> that new function implemented. I think that's nice to have another function
> like ensure_all_started/1-2 in the application module, that makes the entire
> application to be started as one or fail as one if the applications
> specified in the app file couldn't be all started property.
> 

Right. Ideally the 'proper' way to do things would be to use OTP
releases which would figure out that dependency graph you have, and
boots all applications at start time.

A lot of projects, however, never get the ball rolling on releases and
instead use ad-hoc start routines, which ensure_all_started/1-2 would at
least normalize.

> But I still think even when the normal application:start/1-2 function don't
> required all the child applications to be started, still that, I think it
> should do start the sasl application, because I think there is no apparent
> reason why it should not to.
> 

If you do not *need* an application like SASL for your app to work, you
might as well not put it as a dependency of your application. That
solves the problem directly. OTP code will alert through SASL whether it
was started before it or not.

> Another last thing, and I am sorry to bother you, there is a way to turn off
> the intromission of the error_logger in the sasl reports?, because I have
> repeated the same error when happens, one in the sasl like form:
> 
> CRASH REPORT  <0.35.0>                                      2013-08-15
> <snip>
> 
> and another with the error_logger form:
> 
> INFO REPORT  <0.7.0>                                        2013-08-15
> <snip>
> 
> Both reports of the same error but different error_loggers in the same sasl
> report.
> 
> I also tried to silent the error_logger with: {kernel, [{error_logger,
> silent}]}  but still...

Some reports will be duplicated because they come from proc_lib
processes and then the supervisor (CRASH REPORT and SUPERVISOR REPORT,
respectively). I have no idea on how to get rid of only one or the other
of these. You can however get rid of PROGRESS REPORTs by changing the
'errlog_type' SASL variable from 'all' to 'error'.

INFO REPORTs, for their part, are messages generated through
error_logger. These can be disabled by removing the error_logger
handler, either through calling `error_logger:tty(false)' or by setting
'error_logger' as a kernel variable to 'silent'. You can test whether it
worked by calling 'error_logger:info_report("abc")' and seeing if you
get a report.

Now you tried the latest one, but this has to be done as VM argument,
either through sys.config, a config file passed with the -config flag,
or plainly adding '-kernel error_logger silent' to the 'erl' command
line. Doing it after the VM has booted is not an option, but I think
this is the one you attempted.

Regards,
Fred.