IRC meeting

[Shawn Rutledge]

On Nov 26, 2007 4:31 PM, Scott James Remnant <scott at netsplit.com> wrote:
>
> On Mon, 2007-11-26 at 13:40 -0700, Shawn Rutledge wrote:
>
> > On Nov 26, 2007 2:01 AM, Scott James Remnant <scott at netsplit.com> wrote:
> > > disagree with your ratings as well (e.g. I would say that a monolithic
> > > init is good, and plug-in based is bad).
> >
> > Why do you think so?
> >
> Plug-ins are also a major source of exploit attack vector, since they
> allow you to load arbitrary code.

Yep that's a good point.

> All init needs to do is spawn processes, and reap them when they die;
> with some handling for determining when it needs to do the former and
> working out what to do about the latter.

Well at first glance I was inclined to think that when upstart aims to
replace crond and atd, those might be good examples of functionality
that could be plugins.  Then again, the whole point is that events
trigger processes to be launched, and the state of the system clock
can be just another kind of event, so making upstart have cron
functionality is pretty much aligned with its usual behavior.

I suppose in the extreme case, anytime any process wishes to run
another process as root, init could do it (via an IPC request of
course); that way there is just one place where escalation of
privileges is handled.  But I'm sure you can think of some arguments
against that (it sure isn't very traditional).

> It's fine to write separate processes that communicate with init, and
> ask it to spawn or stop processes on its behalf; but that's not a
> plug-in architecture -- that's just decent IPC.

On Nov 26, 2007 4:43 PM, Scott James Remnant <scott at netsplit.com> wrote:
> Debugging interfaces ... why spend time developing debugging interfaces
> for when init crashes?  Why not spend that time making damned sure that
> init can *NEVER* crash?

Yep.

> Upstart, in the extraordinarily unlikely circumstance that it might
> crash (0.3.8 hasn't had a single report of one in the 1 year+ it's been
> out), simply forks and dumps core in the child -- thus generating a

So at least it doesn't halt the system, right?

> Can save snapshots of the system status ... And why is this useful?  If
> you want to snapshot your system, hibernate it.

One example I can think of (and of course I'm not speaking for Ismael)
- Maybe it would be nice to define runlevels by example rather than by
editing code.  E.g. start the services that you want to be running,
kill everything you don't, and then generate a runlevel definition
based on the current system state.  But that can be done by an
external program easily enough.  Not sure if it's even good idea...
just an idea that's all.

> Services garbage collector ... You don't bother to explain what you mean
> here, so it's impossible to discuss.

Maybe it has something to do with maintaining a pool of processes and
scaling based on some sort of demand... but then init has to know too
much to determine the demand.  So some other process would be
necessary to feed events to it when the demand happens (whatever form
that takes).

Or maybe to act like inetd or getty... start processes when a
connection requires them, leave them up a while in case another
connection requires them, then shut them down when they've been idle
long enough.

When devices are hotplugged, something needs to start relevant
processes.  This is already handled by messy script lashups on some
distros, but it's conceivable to just treat that as any other event...
init can respond to any event by launching any process, right?

> Runlevel support ... Runlevels are ancient history, forget about them.

As long as they are named rather than numbered, they could be useful, IMO.


If you look at the list of plugins for init-ng, it's longer than I
would have guessed.  They made everything into a plugin...