IRC meeting

[Scott James Remnant]

On Tue, 2007-11-27 at 01:05 -0200, Ismael Luceno 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?
> > 
> 
> InitNG is facing a big redesign, so these interfaces could really make
> the debugging process a lot easier, but I don't mean we should have
> to implement anything complex, it's only a matter of exporting
> sufficient information in a human readable way and providing a few extra
> callbacks.
> 
But what kind of debugging information is human readable?  Debugging
information is developer readable, and us developers aren't humans,
we're Heroes! :-)

> > Whatever you invent is of little use; if the user knows how to debug
> > init, then they will do so anyway.  For the common case, a core file
> > to attach to a bug report is sufficient.
> > 
> > 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 useful core file.  Ubuntu's apport hook will catch this
> > and ask the user if they'd like to file a bug report.
> > 
> 
> There are other cases in which these interfaces could help, for example,
> in InitNG we had an issue with memory corruption a lot ago, and it took
> really too much time to track.
> 
apt-get install valgrind

> > Control Events can be queued ... err, I have no idea what you mean
> > here. Control events come over a socket, so they're already
> > implicitly queued by the kernel and/or message bus.
> > 
> If you replace init these events are lost.
> 
Depends how you replace init; there are easy ways to reexec a process
and keep the kernel-side socket queues -- in fact, it's arguably harder
to *not* keep them.

> > Can be replaced while running ... Upstart can be replaced while
> > running, your "No" is wrong.
> > 
> OK, but how it does passes the status of the supervised processes to
> the new init?.
> 
Across its own IPC channel - Upstart has supported various methods of
this, and some releases haven't had it, but it's a requirement of the
design.

> > Can save snapshots of the system status ... And why is this useful?
> > If you want to snapshot your system, hibernate it.
> 
> I don't mean to take snapshots of the system, but of the init status,
> the supervised services, and so on...
> 
Why?  What's the use case?

> > Monolithic ... yes, Upstart is monolithic.  This is a GOOD thing.
> > Effort is instead put into making sure that the IPC system is flexible
> > enough for other processes to ask Upstart to do things on their
> > behalf.
> 
> Yeah, that's good, as long as you don't end implementing too much
> functionality in the core, the main reason for InitNG being
> plug-in based is that you can replace parts of it without disturbing the
> rest.
> 
If you have a too much functionality problem, you need to strip your
feature list down because you're trying to do too much.

Slim down the features, take out those that the majority of services
aren't using, etc.  And just get rid of them entirely.

This will reduce the size of your daemon, and thus reduce your debugging
effort and number of bugs.

> > Logging ... Err, we have perfectly good logging daemons in Linux
> > already
> > - why invent another and why build it into pid#1 ?
> 
> Well, there's no reason to implement it, but there's no general
> facility for that InitNG, that's why it says "Limited". I like to
> have a generic interface for this just because some embedded systems do
> not have syslog, in these cases it could be replaced by a simplistic
> logging plug-in.
> 
All systems can have syslog() it's in the libc, and there are various
daemon implementations -- many of which are small enough for embedded
uses.

> > Services garbage collector ... You don't bother to explain what you
> > mean here, so it's impossible to discuss.
> 
> Sorry, that should say Limited.
> 
> When you have some obsolete data in the services database, it could
> be freed easily if the data isn't shared by more than one thing. In the
> InitNG's case that was a problem because of the history plug-in keeps
> accessing data that could have been removed from the db (the plug-in
> was a bad idea anyway, but gives an idea of what could happen).
> 
Err, this seems to be a feature required because of a design flaw.

Upstart has no "services database" in this manner, so it never needs
garbage collection -- the only concern is when a service is deleted or
changed, and in that case, the associated structures are deleted when it
is stopped afterwards.

> > Multi-stage boot support ... Upstart allows you to have as many boot
> > stages as you want, e.g.:
> > 
> > 	start on startup
> > 	script
> > 		initctl emit startup-phase 1
> > 		initctl emit startup-phase 2
> > 		initctl emit startup-phase 3
> > 	end script
> > 
> > You can now run things "on startup-phase 1", etc.
> 
> That's not what I mean. For example, a minimal version of the init
> could be loaded by an initrd, drivers are loaded, the file-systems
> mounted, and then it could pivot_root and the rest of functionality
> could be loaded.
> 
Nothing about the design of upstart precludes this; our plan is that we
start it in the initramfs with one set of /etc/event.d jobs and then the
initramfs instructs it to reexec the one on the real system -- the usual
state passing takes place, and the real system Upstart now has knowledge
of the services still running from the initramfs.

> > Service availability monitoring ... Upstart has various mechanisms for
> > doing this, and is (afaik) the only one that supports supervising
> > daemon processes.
> 
> Does it can tell if daemon X is listening in TCP port Y, and if it's
> accepting connections?
> 
apt-get install monit

This doesn't need to be in init, it will just bloat the daemon.
Provided that init provides decent IPC for starting and stopping
services, this kind of monitoring can be done in a separate process.

> > Events ... "limited" ?  Why do you think so?
> > 
> 
> In the last version of Upstart i tried it were really simplistic, and
> can carry only limited information, but don't misinterpret me, I only
> want something a bit more flexible.
> 
What do you actually want though?  What use cases are you trying to
solve?

Be careful of designing the solution before you know the problem.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20071127/9780e236/attachment.pgp