[Initscripts-ng-devel] Defining the workgroup objectives

[a-aa]

Jay Berkenbilt wrote:

>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.]
>  
>
This is relativly simple to do, as we can grab output from every service
and show it nicly by simply dup'ing the file descriptors (initng does this).

>   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
>   upgrades.
>
> * 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.
>  
>
initng actually has a single.runlevel (not 100% sure it works right now
though), so you could define this yourself.

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