consequence of not using risky_shell

[Ulf Wiger (AL/EAB)]

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