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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
