[Toybox] toybox - init?

[Rich Felker]

On Fri, Dec 12, 2014 at 11:19:43AM -0600, Rob Landley wrote:
> On 12/11/2014 11:16 AM, Rich Felker wrote:
> > On Tue, Dec 09, 2014 at 06:21:04AM -0600, Rob Landley wrote:
> >> On 12/09/2014 03:38 AM, scsijon wrote:
> >>> was just wondering on the status of init within toybox as I'm having a
> >>> look at buildroot and maybe it would be useful there.
> >>>
> >>> thanks
> >>> scsijon
> >>
> >> oneit is in and has worked for years. I'm pondering extending oneit with
> >> a pipe that writes exiting child process pids to a non-PID1 process that
> >> can deal with restarting them if it cares.
> > 
> > For what it's worth, I like that concept. Do you have a way in mind
> > for the non-PID1 process that's receiving these pids to match them up
> > with services that need restarting?
> 
> I haven't done a lot of design work here (I want to research what
> upstart and macosx launchd and so on are currently doing, and see what
> lxc's container launch program is doing, and yes look at systemd to
> understand the full horror; it's a can of worms I haven't opened yet
> because it'll eat my life for a bit, just like sed's been doing).
> 
> But: the non-pid1 process should probably be the one that starts the
> other services in the first place.

Yes, we're on the same page there.

> Basically, oneit's design is "launch a single child process, wait for it
> to exit, do a thing in response". That thing is currenty shutdown or
> reboot, but adding "relaunch the child process" is trivial.
> 
> If oneit gets other things exiting at it, that's because they got
> reparented to init (I.E. their parent exited, which daemonize() does
> automatically). Right now it ignores them, but writing them to a pipe is
> also trivial.
> 
> We should _not_ add anything to oneit that _isn't_ trivial. Policy
> belongs in pid 2.

Agreed.

> > I don't see a good way to do this
> > in general but it seems safe to use pid files (produced by the daemons
> > themselves) here as long as the only purpose you use them for is
> > detecting exit.
> 
> If oneit launches another init-like program as PID 2, and that pid2
> parses its variant of inittab to launch a bunch of processes, then it
> can make a directory of pid files that contain the pid of the service,

That's the hard part -- how does it get these pids? If a process is
behaving properly and not daemonizing itself, then pid2 is the parent
and can use the return value of fork/vfork/posix_spawn directly with
waitpid to determine that the process exited, so there's no need for
the pipe from pid1 in that case. But in the common case, the daemon
daemonized itself (forked a second time internally) and pid2 has no
direct way of getting its pid. Most such daemons write pidfiles, so
pid2 could grab the pid from a pidfile, but this requires some
service-specific path knowledge/logic I think. :(

Is that what you have in mind? I think it probably works.

Rich