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

Fred Hebert mononcqc@REDACTED
Sat Aug 17 03:30:11 CEST 2013

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.


More information about the erlang-questions mailing list