consequence of not using risky_shell

[UAB L/K Peter Andersson]

Ok, we'll call the flag 'async_shell_start' or something like that and
document it for the next release. We wish to keep the current default
behaviour though. You should be able to evaluate shell commands without
risking failure because you don't know if the system has finished
booting yet.

  /Peppe


Magnus Fröberg wrote:
> 
> Hi
> 
> well I didn't comment on the original "risky_shell" mail
> discussion but, uhh, removing the old shell behaviour really
> makes it a hard time debugging bad (maybe hanging) startup
> sequenses in especially highly distributed environments.
> 
> I would recommend not making this flag an undocumented feature
> as it is really needed.
> Actually, I think the default behaviour should be the old
> in an interactive system at least.
> 
> We'll always start our system nodes with this flag enabled!
> 
> /Magnus
> 
> Ulf Wiger (AL/EAB) wrote:
> > Not that I want to gripe too much about the change in the
> > shell behaviour -- that it doesn't become available before the
> > boot sequence is finished...
> >
> > (see http://www.erlang.org/ml-archive/erlang-questions/200412/msg00045.html and follow-ups)
> >
> > but the following situation was a bit annoying:
> >
> >
> > =PROGRESS REPORT==== 11-Feb-2005::15:47:21 ===
> >          application: mnesia
> >           started_at: nonode@REDACTED
> > will wait for tables (time: {15,47,21})
> >
> > User switch command
> >  --> l
> > Unknown command
> >  --> h
> >   c [nn]   - connect to job
> >   i [nn]   - interrupt job
> >   k [nn]   - kill job
> >   j        - list all jobs
> >   s        - start local shell
> >   r [node] - start remote shell
> >   q        - quit erlang
> >   ? | h    - this message
> >  --> s
> >  --> c
> >
> > User switch command
> >  --> j
> >    1  {shell,start,[]}
> >    2* {shell,start,[]}
> >
> >
> > One application in my boot sequence called mnesia:wait_for_tables(Tabs, infinity). Some table doesn't load for some reason, and since the shell doesn't become available until after the completed boot sequence, I had a hard time debugging it. Eventually, I managed to re-install the system, reproduce the error and use rpc:call(...,mnesia,info,[]) from another erlang node.
> >
> > Using Ctrl-G and spawning a new shell doesn't help; the new shell will also hang. Also, starting a remote shell using Ctrl-G from another node fails in the same fashion.
> >
> > The problem? I had forgotten to call application:load(mnesia) before running my function that created a schema, started mnesia, and created the tables (or rather, the install() function should have done this too). As a result, the environment variable telling mnesia where to create the schema wasn't initialized, and the disc_only tables weren't created.
> >
> > It feels like some debugging aide is missing now that there is no shell prompt during boot. Perhaps one should be allowed to start a shell using Ctrl-G even though the main shell isn't finished?
> >
> > /Uffe
> 
> --
> Magnus Fröberg                   Tel: +46 (0)8 545 55 026
> Alteon WebSystems AB             Email: mfroberg@REDACTED
> Sveavägen 151, P.O. Box 6701     WWW: http://www.alteonwebsystems.com
> SE-113 85 Stockholm, SWEDEN