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

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to