[Toybox] Some questions re: init...

[Rob Landley]

On 01/01/14 03:26, ibid.ag at gmail.com wrote:
> I was looking over init, and noticed some things that seemed possibly
> less than optimal, as well as one detail that seemed illogical.

I haven't done any cleanup on this one yet. It could be doing anything...

> First, the oddity:
>    p = getenv("TERM");
> #ifdef VT_OPENQRY
>    int terminal_no;
>    if (ioctl(0, VT_OPENQRY, &terminal_no)) {
>      if (!p || !strcmp(p,"linux")) putenv((char*)"TERM=vt102");
>    } else
> #endif
>    if (!p) putenv((char*)"TERM=linux");
>
> As I read it, this code will set TERM to vt102 if
> (1) the VT_OPENQRY ioctl is supported, AND
> (2) TERM is not set or is set to "linux".

Now I'm curious: typecasting a string constant to char * in your above 
quoted snippet is _crazy_, but it's idiosyncratic crazy of a kind that's 
easy to track. I.E. it looks like an easter egg:

$ grep vt102 busybox/init/init.c
   putenv((char*)"TERM=vt102");

And busybox is doing it too. Presumably copied from the same BSD source. 
Neither ever asked "is there a reason to do this?" Sigh.

There's more than one reason I isolate new submissions in pending until 
I get a chance to go over it with a magnifying glass...

By the way, one thing I worry about with submissions is people assuming 
every BSD license version is exactly the same as every other BSD license 
version, especialy since toybox's version is unique in not having the 
"copy this license text into other things" viral clause.

And yes, BSD is viral. People tend to assume that BSD and GPL are 
compatible in the absence of the advertising clause, but BSD's "copy 
this text verbatim into anything that uses even a snippet of it" could 
be viewed as an 'additional restriction' in GPL terms, and trying to 
hide the conflict by copying the BSD license to the _end_ of the file 
with the GPL boilerplate up front just makes the problem less obvious, 
it doesn't diminish it. Yes, people do that:

   http://git.busybox.net/busybox/tree/networking/ping.c

You can't say nobody's been sued for violating a BSD license because 
AT&T vs BSDI was the first big Unix lawsuit. I have no idea _what_ crazy 
trolls will try. (Then again the BSDi suit sort of established that if 
you rewrite something enough, eventually none of the original code 
remains. I'd rather not lean too heavily on that, though.)

I'll clean it all out when I get around to rewriting init. Possibly from 
scratch. I try not to do that because it discourages contributors, but 
when it comes to licensing I sleep way better at night knowing where the 
code came from.

(A rule of thumb I have is that when I look back at busybox code to 
remind myself how it does something, I wander away from the keyboard for 
~15 minutes afterwards before trying to code up something new. It 
doesn't come up much, 95% of the time strace, the docs (posix 
spec/LSB/man page), and maybe google or wikipedia tell me all I need to 
know. And I just _don't_ look at FSF code. Life's too short and they're 
too trollish.)

> This ioctl returns 1 to MAX_NR_CONSOLES or -1, so
>    if (ioctl(0, VT_OPENQRY, ...))
> will ALWAYS be true since (-1) is still nonzero.
> But I don't see why "is another tty available" should change the
> environment of the one tty.

Do android phones have vga ttys? Do modern systems care much about them? 
Aren't they specified in inittab anyay?

> I see no point to this oddity, especially given the common use of
> "TERM=linux".
> Deleting this would lose the one #ifdef.

I'm pretty happy just hardwiring in TERM=linux if it's not already set. 
(Although possibly this is the shell's job and not init's? Sad there's 
no spec for init...)

> Second, I note that init.c uses a number of x* functions and calls
> error_exit() in some cases...
> These could panic the system on failure.

Indeed. Although if malloc fails for PID 1 your system's pretty hosed to 
begin with. (Remember, it means you ran out of _virtual_ address space, 
or somebody thought it was a good idea to enable strict overcommit in 
which case they get to keep the pieces.)

> -x*alloc/xstrdup/xmsprintf (lines 119-121, 153-155, 169) in the inittab
> parsing is justifable; if malloc fails before init starts anything,
> there's no way we're running anything.
>
> -final_run will panic if fork()/vfork() fails (line 236).

Yeah, it shouldn't. That can happen because of a forkbomb. The 
traditional init behavior is to just wait it out.

It's possible init should be able to do something more proactive in that 
case (killall -1 and relaunch daemons if it persists for more than 15 
seconds maybe), but that's beyond the domain of sysvinit and into 
containers...

> -Do we need to exit on failure to write informational messages?
> I'm thinking of lines 55 (failure to open console) and 439 ("started
> init" message).

Nope. We inherited a console from somewhere (in the form of pid 0-2), if 
we can't open the new one keep using the old one.

Rob