inittab: Start shell only if console is not null

[Harald Becker]

Hi Denys !

 >> Problem means it may make diagnosing other problems a hell.
> Why is it hell? "strace -p1" works.

If you have a working strace ...

... or in other words: Do you have a working Busybox applet for this?

> You are right, I do not use init. Respawn on error is not the only,
> or the biggest problem it has.
>
> http://busybox.net/~vda/init_vs_runsv.html

Ok, this story is funny to read, but has nothing to do with the problems 
of Busybox init. And still there are people which dislike this 
runit/runsv/runsvdir. I'm highly disagreeing with all that information 
of daemons being scattered around so many directories and subdirectories 
and files. I tried this and I got lost on even simple systems. That's 
definitely not the way I like to have my system.

... but that does not change my mind, that Busybox init has a long 
standing bug of uncontrolled and endless respawning processes, and it's 
now at the time to solve this bug, anyhow!

I posted a simple change which stops this endless respawning for some 
kinds of problems, until init gets a SIGHUP (reload inittab).

- This catches open problems with the console (a case which may be 
detected in master, but this one is the only case, which may be handled 
there).

- Exec failures, which usually return with status -1, stop the respawning.

- Getty may return status -1 for open problems (e.g. all pre login 
prompt problems), and for problems when exec to login (as it was done in 
several gettys I used). This won't endless respawn this console, until 
someone could fix the reason and does a SIGHUP.

sysinit and runonce actions get not affected, and respawn actions 
usually run after sysinit actions have gone, so system resources shall 
all be available to start respawning.

If a process exits with any other value except the well known -1 status, 
or if a process is terminated by a signal, it is always triggered for 
restart and not stopped.

... but other solutions to fix the problem may also be welcome ... but 
not if only unspecific redirection to use a different init mechanics.

--
Harald