[Toybox] service

[stephen Turner]

>
> 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
>
>
Yea, looks like he can be a bit.... stubborn. But (and i hate to say it)
when your right, your right and im assuming he was wright (otherwise there
would have been another email of you quoting statistics right?)


> 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():
>
>
I dont remember why but i want to say i didnt jump in because you guys were
talking about a level of programming/system processes that was over my head.


>
> 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
>

im sure as there are lots of choices in init systems there must be a
variety of ways you could set it up.  I'm pushing for stability on my
system and frankly if i dont like your init i dont have to use it, thats
the beauty if linux that i love. But on the other hand I know your not
going to implement a full systemd because you and others dont like the
"lock in" that it apparently pushes.

your discussing what exactly here? that pid 1 would be the init/reaper and
pid 2 would try to retain control of the daemons?

And "a potential side effect is unreaped zombies", But when reading that
the daemons are typically backgrounded and expected to report to pid 1 that
also sounds like it leaves the system open to allow rogue daemons which
either don't get a pid (is that possible?) or decide not to report to pid
1. Im still learning the init process over all and fairly sure everything
gets a pid but so far my reading hasn't answered if a
backgrounded/daemonized service is forced to report to pid 1/init or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150105/70b56135/attachment-0003.htm>