[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems with init

"Joel Baker" <lucifer@lightbearer.com> writes:
> This brings us back to Debian-Policy, which is quite explicit about what
> must be done by init (though, thankfully, it doesn't declare *how* it must
> be done). Please see the Policy Manual, section 10. Unless we intend to
> move all of Debian to this init (hey, if you think it's that much better,
> convince them),

I actually do think its that much better. However, it is pretty
trivial to simulate System V stuff with a shell script that calls the
various rc?.d scripts. What isn't trivial to simulate for real is
actual run levels, but the scripts are trivial.

This may, of course, simply be a place where NetBSD and Debian should
agree to disagree.

Though I doubt we'd be able to convince core Debian to pick up our
init and rc system, I'd recommend having a look at the way that it
works. We designed it based on having used all the other systems and
deciding they weren't what we needed. Like the System V rc system,
there is a separate script for each facility, but unlike System V,
there is no arbitrary numbering to handle the ordering.

The Debian policy manual, I'll note, doesn't tell you how to number
your scripts. You have no way to know, really, what number corresponds
to "disks mounted" or "named running" or whatever. Is that S28 or S72
that you want? What happens when new packages get installed? Does it
change the ordering you want? The way you figure out what a given init
script should be named is purely by lore and what is in the system

In our system, you *do* have a natural way to specify "this program
should be executed after the network is up but before users can log
in", or "this daemon depends on named" or what have you, and it is
easy to read, too. If you want to make sure that sshd can only start
after the point where user logins are permitted (reasonable, eh?) you

  # PROVIDE: sshd

in /etc/rc.d/sshd.

I won't claim we'll ever convince other Unixen to adopt it, but it is
MUCH nicer. The code is all open source, too, and very simple to
understand. FreeBSD is adopting it because they've seen it and they
like it a lot.

The problem is, of course, that it isn't what a naive System V
administrator will expect. It is very easy to learn, and much easier
to use, but it isn't identical to the other system. We've gotten
serious flames about this, and in many ways the flames are right --
being different is a difficulty for people. We don't do what's in
their books. In general, the BSD way traditionally has been to
try to do the "right" solution rather than always the "most
compatible" solution, which is not always the popular move.

We may not be able to all use the same solution in the end, but do
have a quick look at how ours works. Maybe we can get most of what you
want without having to get a new init working.

Perry E. Metzger		perry@wasabisystems.com
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Reply to: