Re: Problems with init
Perry E. Metzger wrote:
>
> "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.
I will note, for the record, that I wasn't trying to be sarcastic in the
above. Nor was I saying it wasn't potentially better. More below.
> This may, of course, simply be a place where NetBSD and Debian should
> agree to disagree.
Well, yes, but Debian GNU/BSD doesn't get that luxury :/
> 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.
Indeed; a good point, and a real benefit. Again, see below.
> 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
> already.
This should probably be fixed, whatever system we go with; it would, in
fact, be a candidate for a bug filed against policy, I would think.
> 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
> do
>
> # PROVIDE: sshd
> # REQUIRE: LOGIN
>
> in /etc/rc.d/sshd.
This most certainly is one way of resolving the above :)
> 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.
Indeed.
> 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.
Out of all of the various distributions I've worked with, Debian is
perhaps one of the *most* likely to accept this line of reasoning. It
also appears to provide the same sort of information to init that the
packaging system provides to the package installer - something that
nobody who uses the Debian packaging system is likely to argue is a bad
thing in any way. It resolves what is, as you pointed out above, a fairly
notable issue in the Policy sphere in a dynamic and adjustable manner,
rather than one which can only be changed by updating a canonical list
of numbers.
If it can truly be made to simulate, in a reasonable fashion, the current
runlevel system well enough to allow for legacy issues and conversion
(something which this project could well prove, by use), then the chances
of having it adopted as the Policy standard are vastly increased.
> 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.
I think my point was, in fact, that wrapping the NetBSD init in scripts
was a faster solution, on the hack level, and likely to be clean enough
in the long term to survive until either Policy is changed, or an init
which supports runlevels is ported. If we have something that *works*,
then the final solution has at least a full release cycle before it has
to be in place. In the current Debian world, that's a relatively long
time.
If we can provide legacy/conversion support, and if someone can demonstrate
that the init can be compiled and used under Linux with relative ease (this
shouldn't be a terribly difficult task, I would think), then I'm all for
offering a revision to policy to change systems.
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://www.lightbearer.com/~lucifer
Reply to: