inittab: Start shell only if console is not null
Hello all, I am configuring a system that can be booted in two ways: - During normal operation, it boots with console=null - For development / maintenance, it boots with console=ttyS0 I am trying to setup inittab so that it will start a shell on the console only if booting in development / maintenance mode (i.e. when console is not null). During this process found out something that I don't understand. If I use this in inittab: ::respawn:/sbin/getty -L 115200 ttyS0 vt100 Then a login shell is always started. However if I do this: console::respawn:/sbin/getty -L 115200 ttyS0 vt100 Then the login shell is only started when console is not null. But why does this happen? According to this [1], when the id field is left blank, the console is used, so shouldn't the above lines be equivalent? Thank you, Guillermo [1] http://spblinux.de/2.0/doc/init.html -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Hi ! console::respawn:/sbin/getty -L 115200 ttyS0 vt100 This is a special Busybox feature. BB uses the id field to specify a tty device, used to start the inittab command. If the device open fails, the inittab line is skipped. From examples/inittab: # : WARNING: This field has a non-traditional meaning for BusyBox init! # # The id field is used by BusyBox init to specify the controlling tty for # the specified process to run on. The contents of this field are # appended to "/dev/" and used as-is. There is no need for this field to # be unique, although if it isn't you may have strange results. If this # field is left blank, then the init's stdin/out will be used. Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Hello Harald, Thank you for your lightning fast answer :) 2014-08-28 9:58 GMT+02:00 Harald Becker : >> console::respawn:/sbin/getty -L 115200 ttyS0 vt100 >> > > This is a special Busybox feature. BB uses the id field to specify a tty > device, used to start the inittab command. Yes I knew this. > If the device open fails, the inittab line is skipped. But I didn't know this. So it seems that if I use "console" as the id, the device open succeeds when the system boots with console=ttyS0 but fails when booting with console=null (not sure why -- shouldn't it be possible to open /dev/null ?). Is my understanding correct? And, if this is indeed correct, then why leaving the id empty works even when booting with console=null ? Thank you, Guillermo ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
But I didn't know this. So it seems that if I use "console" as the id, the device open succeeds when the system boots with console=ttyS0 but fails when booting with console=null (not sure why -- shouldn't it be possible to open /dev/null ?). Have not looked into code, but I ought it depends on the special function of the console. If you specify null as tty it usually succeeds, but if you give the name of a device which fail on open (as with console=null) the entry is skipped. Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
2014-08-28 10:17 GMT+02:00 Harald Becker : > >> But I didn't know this. So it seems that if I use "console" as the id, >> the device open succeeds when the system boots with console=ttyS0 but >> fails when booting with console=null (not sure why -- shouldn't it be >> possible to open /dev/null ?). > > > Have not looked into code, but I ought it depends on the special function of > the console. > If you specify null as tty it usually succeeds, but if you give the name of > a device which fail on open (as with console=null) the entry is skipped. Indeed, opening /dev/null succeeds but opening /dev/console fails when console=null. That's interesting. One additional question. You mention that when the device open fails, the inittab line is skipped. But for respawn lines, is the line really "skipped"? I looked at the source code and it seems that init would keep trying to spawn the process (and of course fail every time). This is because the device open is done inside run() (see [1]), which is already inside the main while loop. Best regards, Guillermo [1] https://gitorious.org/busybox/busybox/source/6e8e666bd9d62772713af7f06ce9495d21d51f4e:init/init.c#L348 > > Harald > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
On Thu, Aug 28, 2014 at 10:08 AM, Guillermo Rodriguez Garcia wrote: > 2014-08-28 9:58 GMT+02:00 Harald Becker : >>> console::respawn:/sbin/getty -L 115200 ttyS0 vt100 >>> >> >> This is a special Busybox feature. BB uses the id field to specify a tty >> device, used to start the inittab command. > > Yes I knew this. > >> If the device open fails, the inittab line is skipped. > > But I didn't know this. So it seems that if I use "console" as the id, > the device open succeeds when the system boots with console=ttyS0 but > fails when booting with console=null (not sure why -- shouldn't it be > possible to open /dev/null ?). > > Is my understanding correct? init won't try to open /dev/null for "console::respawn:/sbin/getty -L 115200 ttyS0 vt100" line. It will try to open /dev/console. If that open fails, then respawning will not be done. Therefore, your question should be "why when I boot my kernel with console=null, /dev/console can't be opened?" > And, if this is indeed correct, then why leaving the id empty works > even when booting with console=null ? The "::respawn:/sbin/getty -L 115200 ttyS0 vt100" line (empty id case) does not try to open anything. It just uses already-opened file descriptors 0,1,2 for stdio. It can't "fail to open /dev/something" since it does not open anything. (Note that init does ensure that file descriptors 0,1,2 are open even if they weren't open when it was started by kernel. See console_init() in the source). -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Hi Denys, 2014-08-28 11:05 GMT+02:00 Denys Vlasenko : > On Thu, Aug 28, 2014 at 10:08 AM, Guillermo Rodriguez Garcia >> But I didn't know this. So it seems that if I use "console" as the id, >> the device open succeeds when the system boots with console=ttyS0 but >> fails when booting with console=null (not sure why -- shouldn't it be >> possible to open /dev/null ?). >> >> Is my understanding correct? > > init won't try to open /dev/null for > "console::respawn:/sbin/getty -L 115200 ttyS0 vt100" > line. It will try to open /dev/console. Right. This was a misunderstanding on my side. I stand corrected. > If that open fails, then respawning will not be done. Actually I'm testing this and it seems that init keeps spawning child processes forever, every second. Inside run(), vfork succeds but then the device open fails and the child process _exits(). Is there a way to have init completely skip the line if the controlling tty is not valid or cannot be opened. > > Therefore, your question should be > "why when I boot my kernel with console=null, > /dev/console can't be opened?" Indeed. >> And, if this is indeed correct, then why leaving the id empty works >> even when booting with console=null ? > > The "::respawn:/sbin/getty -L 115200 ttyS0 vt100" line > (empty id case) does not try to open anything. > It just uses already-opened file descriptors 0,1,2 for stdio. > It can't "fail to open /dev/something" since it does not open anything. OK right. I was misled by the wording here: http://spblinux.de/2.0/doc/init.html , where it says that "If this field is left blank, the controlling tty is set to the console". My fault. Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Hi Denys ! If that open fails, then respawning will not be done. Actually I'm testing this and it seems that init keeps spawning child processes forever, every second. Inside run(), vfork succeds but then the device open fails and the child process _exits(). Is there a way to have init completely skip the line if the controlling tty is not valid or cannot be opened. May be we can disable the inittab entry, when the spawn fail (e.g. process status code -1 or 127), until init get a SIGHUP (reload inittab)? Therefore, your question should be "why when I boot my kernel with console=null, /dev/console can't be opened?" Indeed. The problem doesn't seam to be the open. If you set console=null the open shall succeed on the dummy device, but setting this device for none blocking io or usage as a tty will fail. So "opening the console device" does not only belong to the open() call. May be this is the answer to the question, why this "open" fails. Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Hi Denys!
If that open fails, then respawning will not be done.
Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the child process _exits().
Is there a way to have init completely skip the line if the
controlling tty is not valid or cannot be opened.
May be we can disable the inittab entry, when the spawn fail (e.g.
process status code -1 or 127), until init get a SIGHUP (reload inittab)?
I suggest doing something like the attached patch (this is just for
clarification - not fully tested).
--
Harald
--- init.c 2014-08-05 21:57:18.0 +0200
+++ init.new.c 2014-08-28 14:35:12.964048564 +0200
@@ -480,7 +480,7 @@
/* Open the new terminal device */
if (!open_stdio_to_tty(a->terminal))
- _exit(EXIT_FAILURE);
+ _exit(-1);
/* NB: on NOMMU we can't wait for input in child, so
* "askfirst" will work the same as "respawn". */
@@ -533,7 +533,7 @@
_exit(-1);
}
-static struct init_action *mark_terminated(pid_t pid)
+static struct init_action *mark_terminated(pid_t pid, int status)
{
struct init_action *a;
@@ -545,7 +545,7 @@
);
for (a = init_action_list; a; a = a->next) {
if (a->pid == pid) {
-a->pid = 0;
+a->pid = WIFEXITED(status) && WEXITSTATUS(status) == 255 ? (pid_t)-1 : 0;
return a;
}
}
@@ -562,8 +562,9 @@
/* Wait for any child (prevent zombies from exiting orphaned processes)
* but exit the loop only when specified one has exited. */
while (1) {
- pid_t wpid = wait(NULL);
- mark_terminated(wpid);
+ int status;
+ pid_t wpid = wait(&status);
+ mark_terminated(wpid, status);
/* Unsafe. SIGTSTP handler might have wait'ed it already */
/*if (wpid == pid) break;*/
/* More reliable: */
@@ -878,6 +879,7 @@
signal(SIGCONT, record_signo);
while (1) {
+ int status;
pid_t wpid;
if (bb_got_signal == SIGCONT)
@@ -886,8 +888,8 @@
* which we waitfor() elsewhere! waitfor() must have
* code which is resilient against this.
*/
- wpid = wait_any_nohang(NULL);
- mark_terminated(wpid);
+ wpid = wait_any_nohang(&status);
+ mark_terminated(wpid, status);
sleep(1);
}
@@ -969,10 +971,19 @@
return sigs_seen;
bb_got_signal = 0;
sigs_seen = 1;
-#if ENABLE_FEATURE_USE_INITTAB
if (sig == SIGHUP)
+ {
+ struct init_action *a;
+
+ for (a = init_action_list; a; a = a->next)
+ {
+if (a->pid == (pid_t)-1)
+ a->pid = 0;
+ }
+#if ENABLE_FEATURE_USE_INITTAB
reload_inittab();
#endif
+ }
if (sig == SIGINT)
run_actions(CTRLALTDEL);
}
@@ -1205,17 +1216,18 @@
if (maybe_WNOHANG)
maybe_WNOHANG = WNOHANG;
while (1) {
+ int status;
pid_t wpid;
struct init_action *a;
/* If signals happen _in_ the wait, they interrupt it,
* bb_signals_recursive_norestart set them up that way
*/
- wpid = waitpid(-1, NULL, maybe_WNOHANG);
+ wpid = waitpid(-1, &status, maybe_WNOHANG);
if (wpid <= 0)
break;
- a = mark_terminated(wpid);
+ a = mark_terminated(wpid, status);
if (a) {
message(L_LOG, "process '%s' (pid %d) exited. "
"Scheduling for restart.",
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
On Thu, Aug 28, 2014 at 2:45 PM, Harald Becker wrote: If that open fails, then respawning will not be done. >>> >>> >>> Actually I'm testing this and it seems that init keeps spawning child >>> processes forever, every second. Inside run(), vfork succeds but then >>> the device open fails and the child process _exits(). >>> >>> Is there a way to have init completely skip the line if the >>> controlling tty is not valid or cannot be opened. >> >> >> May be we can disable the inittab entry, when the spawn fail (e.g. process >> status code -1 or 127), until init get a SIGHUP (reload inittab)? > > > I suggest doing something like the attached patch (this is just for > clarification - not fully tested). I don't like special-casing exit code values. The "proper" fix is to open the file in the parent, before fork. Then the failure can be detected in the parent. Arguably, "why bother" is a solution too. ;) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Denys ! > I don't like special-casing exit code values. The "proper" fix is to open the file in the parent, before fork. Then the failure can be detected in the parent. This patch not only disables entries due to open failure of the console, it also disables endless respawning of processes when the given program can't be executed, a case which usually return -1 (which results in an exit code of 255). There is no other special-casing of exit codes than this one used for decades. The result shall be: - If an action entry fails with an exit code of -1, the action entry gets blocked and not automatically respawned until next SIGHUP. - If an action process exits with any other legal value or is exited by a signal the corresponding action is marked "available" and will be respawned after this one second delay. This fixes a long standing problem with Busybox init, which will endless respawn unavailable services give in inittab, and also triggers when the init action can't be started due to any other error (like console open failure). -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
On Thu, Aug 28, 2014 at 3:14 PM, Harald Becker wrote: >> I don't like special-casing exit code values. >> >> The "proper" fix is to open the file in the parent, before fork. >> Then the failure can be detected in the parent. > > This patch not only disables entries due to open failure of the console, it > also disables endless respawning of processes when the given program can't > be executed, a case which usually return -1 (which results in an exit code > of 255). There is no other special-casing of exit codes than this one used > for decades. > > The result shall be: > > - If an action entry fails with an exit code of -1, the action entry gets > blocked and not automatically respawned until next SIGHUP. It's not a clear-cut improvement. What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY). What if execve fails because /usr/bin/BAR does not exist YET? What if some people who use bbox init expect respawn to retry until success in these cases? -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Denys ! What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY). What if execve fails because /usr/bin/BAR does not exist YET? Both cases can be solved when startup code send a SIGHUP to init when all this stuff is available (at end of rc scripts do kill -SIGHUP 1) Not to talk about: Normal respawning actions are started when sysinit actions has finished. All required devices and file systems shall be online at this time and so respawn actions will not get affected. What if some people who use bbox init expect respawn to retry until success in these cases? What about all those people who can't use Busybox init due to its endless and relatively fast respawning (wasting process id's). Standard SYSV init never did this (detects fast respawning then puts action to sleep for minutes or exponential increasing time). Ok, this full "fast" respawn detection is complicated stuff, so I have chosen a simpler approach. Your argument here is confusing. Do you really look for people using bbox init due to it's long standing bug of endless respawning unavailable services? May intention was to do one step further into the right direction not to do endless uncontrolled respawning. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
2014-08-28 15:48 GMT+02:00 Harald Becker : >> What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY). >> What if execve fails because /usr/bin/BAR does not exist YET? > > Both cases can be solved when startup code send a SIGHUP to init when all > this stuff is available (at end of rc scripts do kill -SIGHUP 1) > > Not to talk about: Normal respawning actions are started when sysinit > actions has finished. All required devices and file systems shall be online > at this time and so respawn actions will not get affected. > > >> What if some people who use bbox init expect respawn to retry until >> success >> in these cases? > > > What about all those people who can't use Busybox init due to its endless > and relatively fast respawning (wasting process id's). Standard SYSV init > never did this (detects fast respawning then puts action to sleep for > minutes or exponential increasing time). Ok, this full "fast" respawn > detection is complicated stuff, so I have chosen a simpler approach. > > Your argument here is confusing. Do you really look for people using bbox > init due to it's long standing bug of endless respawning unavailable > services? May intention was to do one step further into the right direction > not to do endless uncontrolled respawning. > FWIW, I have tested the patch locally and I can confirm that it does the job for me perfectly fine. -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
On Thu, Aug 28, 2014 at 3:48 PM, Harald Becker wrote: >> What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY). >> What if execve fails because /usr/bin/BAR does not exist YET? > > Both cases can be solved when startup code send a SIGHUP to init when all > this stuff is available (at end of rc scripts do kill -SIGHUP 1) > > Not to talk about: Normal respawning actions are started when sysinit > actions has finished. All required devices and file systems shall be online > at this time and so respawn actions will not get affected. > >> What if some people who use bbox init expect respawn to retry until >> success in these cases? > > > What about all those people who can't use Busybox init due to its endless > and relatively fast respawning (wasting process id's). I imagine we would have these people complaining on the mailing list by now. > Your argument here is confusing. Do you really look for people using bbox > init due to it's long standing bug of endless respawning unavailable > services? My argument is that before adding code, it makes sense to ponder whether we really have a real problem here. If one respawn per second a big problem? I'm not sure. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Denys ! > My argument is that before adding code, it makes sense to ponder whether we really have a real problem here. Do you really insist on this endless respawning NOT BEING A BUG??? I don't understand your stand point. If one respawn per second a big problem? I'm not sure. Problem means it may make diagnosing other problems a hell. It is the reason I neglect to use unpatched Busybox init for most of my applications and I know several people here in Germany thinking the same that this is really bad. I really wonder why this has not bean fixed earlier (anyhow not insisting on my patch). I even asked for this around 1995 to 1997 (as far as I remember), but it has been neglected due to the KISS principle and things shall be small for embedded devices ... but today we got more and more desktop related patches blowing up things more than that simple approach. And still you insist on this endless uncontrolled respawning? If you really like this endless respawning, why don't you use runit? I think it's the time to fix init to avoid endless uncontrolled respawning. Anyhow! -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
2014-08-28 16:38 GMT+02:00 Harald Becker : >> My argument is that before adding code, it makes sense to ponder >> >> whether we really have a real problem here. > > > Do you really insist on this endless respawning NOT BEING A BUG??? > > I don't understand your stand point. > > >> If one respawn per second a big problem? I'm not sure. > > > Problem means it may make diagnosing other problems a hell. It is the reason > I neglect to use unpatched Busybox init for most of my applications and I > know several people here in Germany thinking the same that this is really > bad. I really wonder why this has not bean fixed earlier (anyhow not > insisting on my patch). I even asked for this around 1995 to 1997 (as far as > I remember), but it has been neglected due to the KISS principle and things > shall be small for embedded devices ... but today we got more and more > desktop related patches blowing up things more than that simple approach. > And still you insist on this endless uncontrolled respawning? If you really > like this endless respawning, why don't you use runit? > > I think it's the time to fix init to avoid endless uncontrolled respawning. Perhaps this fix could be implemented with a CONFIG_ option. You may either enable it by default and wait to see if there are complaints (I don't really think this would break any actual usage), or you may disable it by default so that only people who want the "fixed" behaviour would get it. But either way I think it would be convenient to fix this. Guillermo ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Just for the record, I am now working around this as follows: console::respawn:/sbin/ifconsole /sbin/getty -L 115200 ttyS0 vt100 /sbin/ifconsole is a shell script that checks if /dev/console can be opened; if so, the line is executed; otherwise it just sleeps forever (to prevent the respawning). This works, but it is a crude hack. I really believe that Harald's suggestion would be the right thing to do here. Guillermo 2014-08-28 17:21 GMT+02:00 Guillermo Rodriguez Garcia : > 2014-08-28 16:38 GMT+02:00 Harald Becker : >>> My argument is that before adding code, it makes sense to ponder >>> >>> whether we really have a real problem here. >> >> >> Do you really insist on this endless respawning NOT BEING A BUG??? >> >> I don't understand your stand point. >> >> >>> If one respawn per second a big problem? I'm not sure. >> >> >> Problem means it may make diagnosing other problems a hell. It is the reason >> I neglect to use unpatched Busybox init for most of my applications and I >> know several people here in Germany thinking the same that this is really >> bad. I really wonder why this has not bean fixed earlier (anyhow not >> insisting on my patch). I even asked for this around 1995 to 1997 (as far as >> I remember), but it has been neglected due to the KISS principle and things >> shall be small for embedded devices ... but today we got more and more >> desktop related patches blowing up things more than that simple approach. >> And still you insist on this endless uncontrolled respawning? If you really >> like this endless respawning, why don't you use runit? >> >> I think it's the time to fix init to avoid endless uncontrolled respawning. > > Perhaps this fix could be implemented with a CONFIG_ option. You may > either enable it by default and wait to see if there are complaints (I > don't really think this would break any actual usage), or you may > disable it by default so that only people who want the "fixed" > behaviour would get it. > > But either way I think it would be convenient to fix this. > > Guillermo -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
On Thu, Aug 28, 2014 at 4:38 PM, Harald Becker wrote: > Denys ! > >> My argument is that before adding code, it makes sense to ponder >> >> whether we really have a real problem here. > > Do you really insist on this endless respawning NOT BEING A BUG??? I'm saying it is not clear-cut. >> If one respawn per second a big problem? I'm not sure. > > > Problem means it may make diagnosing other problems a hell. Why is it hell? "strace -p1" works. > It is the reason > I neglect to use unpatched Busybox init for most of my applications and I > know several people here in Germany thinking the same that this is really > bad. I really wonder why this has not bean fixed earlier (anyhow not > insisting on my patch). I even asked for this around 1995 to 1997 (as far as > I remember), but it has been neglected due to the KISS principle and things > shall be small for embedded devices ... but today we got more and more > desktop related patches blowing up things more than that simple approach. > And still you insist on this endless uncontrolled respawning? If you really > like this endless respawning, why don't you use runit? 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 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
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
