On Saturday 05 April 2008 21:20, Harald Kuethe wrote:
> >> init: after waitfor(run(a))
> >> *signals
> >> *RESPAWN
> >> *ASKFIRST
> >> init: before a->pid = run(a)
> >> init: run vfork returned 0
> >>
> >> Please press Enter to activate this console.
> >> init: run vfork returned 80
> >
> >
> >
> > if (BB_MMU && (a->action_type & ASKFIRST)) {
> > static const char press_enter[] ALIGN1 =
> > #ifdef CUSTOMIZED_BANNER
> > #include CUSTOMIZED_BANNER
> > #endif
> > "\nPlease press Enter to activate this console. ";
> > char c;
> > /*
> > * Save memory by not exec-ing anything large (like a shell)
> > * before the user wants it. This is critical if swap is not
> > * enabled and the system has low memory. Generally this will
> > * be run on the second virtual console, and the first will
> > * be allowed to start a shell or whatever an init script
> > * specifies.
> > */
> > messageD(L_LOG, "waiting for enter to start '%s'"
> > "(pid %d, tty '%s')\n",
> > a->command, getpid(), a->terminal);
> > full_write(1, press_enter, sizeof(press_enter) - 1);
> > while (safe_read(0, &c, 1) == 1 && c != '\n')
> > continue;
> > }
> >
> >
> > DOH!
> >
> > Try this patch.
> > --
> > vda
> >
>
> This patch works! (as expected since it is using a fork instead of vfork in
> our case)
> Do I use a weird inittab or what is special here?
No, my conversion to make init work on NOMMU
was handling "askfirst" inconsistently.
It was treating "askfirst" as "respawn" _only_ on NOMMU,
but was using vfork _always_, even on MMU! So in "askfirst" case
init was stuck waiting for the child.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
