[erlang-questions] inets services startup

[Serge Aleynikov]

Dan,

I can see how your suggestion can work well for some special cases, but 
I am not sure how it can help when you have a bad/missing value in the 
inets configuration that would cause one of the inets services to fail 
starting without crashing inets.  The later is the problem I am having 
as I don't want to see inets application being started if httpd service 
cannot come up given its configuration.  The fact that it requires a 
separate config file is merely an inconvenience I can live with.

Serge

Daniel Goertzen wrote:
> We've used linux FUSE with great success to integrate a number of 3rd 
> party apps in an embedded system.  Whenever one of those apps reads a 
> config file, our FUSE code generates the config on the fly.
> 
> Mind you, this was all in C++, but there is some work being done on an 
> erlang binding for FUSE: 
> http://www.erlang.org/pipermail/erlang-questions/2007-January/025055.html
> 
> I don't know if this would solve all your problem... and it would force 
> you to use linux.
> 
> Dan.
> 
> Serge wrote:
>> I've been trying to work around the inets startup issue described in the 
>> former email of failing to crash inets in case of a inability to start 
>> for a httpd service given its configuration file.  I also need to run 
>> inets as an embedded application.  The best solution I could come up 
>> with was not to use inets' own supervisor, but start a custom one, 
>> register it as 'httpd_sup' so that httpd_sup:start_child/1 could be used 
>> to link to this supervisor.  Since httpd_sup:start_child/1 doesn't 
>> accept the supervisor name I am enforced to call this supervisor 
>> 'httpd_sup'.  Are there any more elegant ways of embedding inets and 
>> solving the described issue aside from patching the distribution?
>>
>> What I would like to see implemented in inets is a function:
>>
>> httpd_sup:start_child(Supervisor, ConfigList)
>>    Supervisor = atom()            % Name of a parent supervisor
>>    ConfigList = [{Option, Value}] % What's returned by httpd_conf:load/1
>>
>> Serge
>>
>>
>> -module(test_app).
>> -behaviour(application).
>>
>> %% application callbacks
>> -export([start/2, stop/1]).
>>
>> %% supervisor callbacks
>> -export([init/1]).
>>
>> %%%-------------------------------------------------------------------
>> %%% Callbacks functions from application
>> %%%-------------------------------------------------------------------
>>
>> %%--------------------------------------------------------------------
>> %% @spec start(Type, StartArgs) -> Result
>> %%         Result = {ok, Pid}        |
>> %%                  {ok, Pid, State} |
>> %%                  {error, Reason}
>> %% @doc Start application callback
>> %% @end
>> %% @private
>> %%--------------------------------------------------------------------
>> start(_Type, StartArgs) ->
>>      {ok, ConfigFile} = application:get_env(test_app, httpd_config_file),
>>      case supervisor:start_link({local, httpd_sup}, ?MODULE, []) of
>>      {ok, Pid} ->
>>          case catch httpd_sup:start_child(ConfigFile) of
>>          {ok, _Child} ->
>>              {ok, Pid};
>>          {error,Error} ->
>>              {error, Error}
>>          end;
>>      {error, Error} ->
>>          {error, Error}
>>      end.
>>
>> %%--------------------------------------------------------------------
>> %% @spec stop(Reason) -> any
>> %% @doc Stop application callback
>> %% @end
>> %% @private
>> %%--------------------------------------------------------------------
>> stop(_Reason) ->
>>      ok.
>>
>> %%%-------------------------------------------------------------------
>> %%% Callback functions from supervisor
>> %%%-------------------------------------------------------------------
>>
>> %%%-------------------------------------------------------------------
>> %%% Internal functions
>> %%%-------------------------------------------------------------------
>>
>> init(_Args) ->
>>      {ok, {{one_for_one, 10, 3600}, []}}.
>>
>>
>> Serge Aleynikov wrote:
>>   
>>> While accidentally entering wrong information in inets' server 
>>> configuration file I got an error report stating that a child spec was 
>>> not created.  As a result the corresponding service didn't get started.
>>>
>>> Upon examining sources, I found the following code with 
>>> exit({error,Reason}) commented out:
>>>
>>> httpd_sup.erl:
>>> ==============
>>> child_spec([], Acc) ->
>>>      Acc;
>>> child_spec([{httpd, HttpdService} | Rest], Acc) ->
>>>      NewHttpdService = mk_tuple_list(HttpdService),
>>>      %%    Acc2 = child_spec2(NewHttpdService,Acc),
>>>      NewAcc=
>>>      case catch child_spec2(NewHttpdService) of
>>>          {ok,Acc2} ->
>>>          [Acc2|Acc];
>>>          {error,Reason} ->
>>>          error_msg("failed to create child spec for ~n~p~ndue to: ~p",
>>>                [HttpdService,Reason]),
>>> %       exit({error,Reason})
>>>          Acc
>>>      end,
>>>      child_spec(Rest,NewAcc).
>>>
>>> I was wondering what the authors had in mind by somewhat silently 
>>> ignoring the critical error at startup.  Wouldn't it be proper to 
>>> uncomment that line?
>>>
>>> Serge