IRC meeting

[Ismael Luceno]

El Mon, 26 Nov 2007 23:43:58 +0000
Scott James Remnant <scott at netsplit.com> escribió:

> On Sun, 2007-11-25 at 18:24 -0200, Ismael Luceno wrote:
> 
> > Look at the following document:
> > http://ismael.linuxdevel.net/init_issues.html
> > 
> A reasonably quick reply to the issues here in the interest of
> starting debate.  There's almost no text backing up why you think
> these things are important, so it's hard to discuss.
> 

I hadn't the time to finish it...


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

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

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

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

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

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

> Memory management ... this seems to be a simple critique of
> programming style?  How is this relevant for feature comparison?

Well, InitNG really needs some kind of memory management, and Upstart
has a good one, that's all :).

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

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

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

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

> Scripts ... why does this matter?

Well, it doesn't matter if the interpreter is external...

> Runlevel support ... Runlevels are ancient history, forget about them.
> That being said, Upstart's sysv compat tools emulate them so you can't
> tell the difference.
> 
> 

> Dynamic service reconfiguration ... supported via D-BUS, but, why
> would a service do it to itself?

A service should be able to reconfigure itself in some situations, for
example, if a service can use some feature of another service, you can
tell the first service to start without it's soft-dependency and later
restart it and add the dependency on the second service.

D-BUS is not an option in some systems. For example, I have an old
Pentium III as server, and it doesn't uses D-BUS, why it should?

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

-- 
Ismael Luceno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20071127/4daedff3/attachment.pgp