[Initscripts-ng-devel] Defining the workgroup objectives

Jay Berkenbilt qjb at debian.org
Tue Jul 26 00:44:42 UTC 2005

Henrique de Moraes Holschuh <hmh at debian.org> wrote:

> Should we have any other objectives? Should we drop any of the
> objectives listed above, or modify them?  Note that defining the
> design goals for each objective are a separate issue.

I have several suggestions for things that are a little higher level
than the kinds of things that you're talking about but may still be
within scope or relevant.  Please let me know if they are not.  (In
that case, a clear statement of scope would be in order ;-]) I hope
that I am not stepping into the territory of "defining the design
goals" as you specifically mentioned was a separate issue.  My
suggestions below have more of a "requirements" feel than a "design"
feel to them.

 * Is it worth including something about the appearance of the booting
   system in the list of objectives?  I think having a standard
   interface for presenting diagnostics to the user (important
   messages, basic success and failure) is pretty important and could
   get tricky for a dependency-based system that may start multiple
   services at once.  We have to remember to keep this in mind as we
   design (or adopt) a solution.  [Note: I have not looked at any of
   the dependency-based systems, so if they've already addressed this,
   I'm not aware of it.]

   Obvious comment: Fedora, Ubuntu, and likely others present a much
   more streamlined boot appearance to users while still logging all
   important information.  When watching debian boot, it's hard even
   for an advanced system administrator to know which of the reported
   failures are important and which ones aren't.

 * Support for interactive startup (as is available in Fedora).
   Supporting this is low-impact as it doesn't really impact
   individual init scripts, but if the interface supports it in a
   well-defined way, init scripts that may start more than one service
   could hook into it to allow the individual services to be
   controlled separately.  Interactive startup is great for situations
   in which a system's startup process is being debugged, to
   temporarily work around network outages, or during system

 * Is it out of scope to define or suggest policy about what should
   and should not happen in single user mode?  I've personally always
   felt Debian's boot process does far too much in single user mode,
   even if it does allow you to hit CTRL-C.  For example, I don't
   think network interfaces should be started there.  I think single
   user mode should do the minimum required to get the user to a
   shell.  In particular, it shouldn't be doing stuff that may hang or
   cause problems.

   Since it will be very hard to get consensus on this, another
   possible way to handle this might be to specify an interface that
   supports administrators tweaking some of this stuff and having
   those tweaks survive across upgrades in much the same way disabling
   service survives across upgrades in Debian currently.

 * Debian lacks a "nice" way to control what does and doesn't start.
   Having a program like update-rc.d (or, as you suggest,
   register-rc.d) is great for maintainer scripts, but it's not really
   intended to be used by end users.  I like the fact that update-rc.d
   is well-behaved when it comes to respecting users' links, and it is
   a decent interface (main objectives of this group notwithstanding)
   for maintainers to use to install init scripts in the right place,
   but I think chkconfig (from Red Hat, earlier from IRIX) is nicer
   than manually managing the links in any number of ways, and
   encoding the expected sequence (or dependency, or whatever we end
   up with) in the init script itself seems like a worthwhile thing to
   do.  Such functionality must not sacrifice Debian's current ability
   to preserve an administrator's choices about where and whether
   things start.

Even if these items end up showing up again later on when actual
requirements for the system are constructed (after more fundamental
decisions are made), I think these are some points worth remembering
as they will be important to many users, particularly those who don't
necessarily have a deep understanding of the boot process.

Jay Berkenbilt <qjb at debian.org>

More information about the initscripts-ng-devel mailing list