[Toybox] service

[Rob Landley]

On 01/04/2015 06:50 PM, stephen Turner wrote:
> Hey Rob, Dalias wrote an article and i think i agree with it (I
> admittedly may not know my out port from a hole in the ground but i have
> been doing a lot of reading this weekend) where he talks about the
> issues with init and pid 1. There he wrote a like 10 line init that only
> did what it absolutely had to and then called rc. I certainly think it
> fits your "as little as possible" mentality with this project and could
> be a good fit. it would be one program i doubt you would ever touch
> again thats for sure. He licensed it under a BSD but originally it was
> open so maybe he would offer us that code (or you could modify it) ?
> 
> http://ewontfix.com/14/
> 
> Whats your thought about this minimalist init? all of the fancy bells
> and whistles can be outsourced to something else im sure.

I read that when it came out and I believe at least one thing in it was
him quoting me from earlier irc discussions on #musl. :)

We've been butting heads for years and he _does_ often convince me I'm
wrong. Here's such an example from 2006, you'll note toybox verror_msg()
in lib/lib.c is currently using strerror() instead of %m:

http://lists.busybox.net/pipermail/busybox/2006-June/056537.html

His minimal init isn't that far off from my oneit. (Mine implements
console switching to get a controlling tty for the child process, his
expects the child to do that.)

A week or two back we were talking about how to get pid 1 to export the
list of PID exits from reparent_to_init():

http://lists.landley.net/pipermail/toybox-landley.net/2014-December/003810.html

If dreamhost ever gets its darn web archive caught up there's more to
that conversation. (I have a really hard time navigating gmane's web
interface to actually _find_ any specific post.)

I haven't done it yet because I haven't figured out the best way to
export the data. (Writing to a pipe or fifo can block pid 1, not sure
how complicated I want to get trying to avoid that? If the pid 2 it's
talking to goes away or isn't keeping up with the incoming data due to
forkbomb or similar, there isn't actually a _good_ solution. I should
probably just do the simple version first and then wait for it to cause
somebody a problem requiring more code. The potential symptom is
unreaped zombies which isn't immediately game over, so... I guess if you
tell "oneit -f /dev/fifoname" and nobody's reading from it, that's pilot
error in your system setup? Maybe? (And if the program that _should_ be
reading from it is the command oneit ran, then oneit responds to it
exiting by relaunching it or rebooting anyway, so... Hmmm, write with a
timeout? I can do that with poll(), which gets me back to genericizing
the main loop in netcat. And in fact the write with a timeout would be
"oneit -w SECONDS" because it's more or less a "watchdog"... ) Although
if you're saying "I am writing to pid 2" then I could just have fd 3
contain the pipe I'm writing to, the child process can inherit a
filehandle. Dunno if that's cleaner or uglier than
/dev/globallyvisibilefilename

Anyway, as you can see there's some design work to do...

Rob

 1420466330.0