init observations

[Paul A Houle]

Kenneth Porter wrote:

>
> It's funny how the discussion gets lost in a focus on speed, and the 
> other benefits that are more important to servers seem to get ignored 
> (at least for discussion).
>
> To me the big wins are explicit expression of dependencies instead of 
> numbered start/stop order, and better integration with hot-plugging.
>
> The speed is nice, but to me it's the ability of the system to 
> describe the desired relationships clearly that makes the admin's life 
> more bearable.
>
    I'd like to see a system that's smart about dependencies,  but I've 
got some fear that the cure could be worse than the disease.  I'd want 
the ability to break the rules if I want to.

    Another problem is that dependencies aren't always so clear:  does 
Apache depend upon Tomcat or does Tomcat depend on Apache?

* Apache can't handle .jsp files w/o Tomcat,  but
* A Java application runs just fine in Tomcat,  except that you need 
Apache for the outside world to see it.

    Tomcat gets wedged often,  and needs a kick.  I don't need to 
restart the web server in this case.  I often kick Apache because I 
changed the configuration files...  I don't need to trash the 
application state in Tomcat when I do this.  Although I want these 
services to start together,  things would go smoother if I could kick 
them independently.

    On the other hand,  if you're using Oracle from PHP,  you'll lose 
your connection to the Listener if you kick Oracle and don't kick Apache.

    I'm not completely happy with dependencies being represented in the 
'init file' (or generalization thereof) because a dependency is a 
function of two software systems,  not a product of one.  For instance,  
imagine that I'm running the Apache that comes with Fedora/RH,  and I'm 
using it in a 'web services' or 'application server' mode where it 
depends on some other daemons such as Tomcat,  mcached,  etc that I've 
installed myself.  Well,  if I hacked the init script for Apache to add 
the new dependencies,  that may cause problems for rpm management.

    (I've got this problem with the .desktop file system for creating 
the Gnome menu -- I might want to attach my own categories such as 
"Favorite" or "Available in Kiosk Mode",  but hacking 100 .desktop files 
would be a disaster)

    It might be easy to create 'virtual' services that are a bundle of 
other services,  and this might even be a replacement for numbered 
runlevels...  A 'desktop' service,  for instance,  brings up X Windows,  
Xft,  input method daemons and all that.

----

    I think it's good that we're having a free-wheeling discussion of 
all aspects of a new init system because it's important that it has a 
design that embraces all of the things we're going to want to do with 
it.  A new init system ought to facilitate fast boot and it ought to be 
flexible enough to support software suspend -- if we pick bad data 
structures,  we'll have a system that we'll be cursing for years to come.

    I'm particularly concerned about customizability.  Different shops 
have different ideas about the 'right' way to manage systems,  and there 
are many questions that have no conclusive answer.  It's one thing for 
Gnome to be tough to customize (if I hate the panel,  I can install a 
different panel) but I'd hate to have to do surgery on initd for every 
FC5 or RHEL 5 box I maintain.