Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Why simpleinit-msb ?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: Dragan Stanojevic - Nevidljivi <invisible AT hidden-city.net>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Why simpleinit-msb ?
  • Date: Wed, 15 Jun 2005 14:37:06 -0700

On Wed, Jun 15, 2005 at 03:44:49PM +0200, Dragan Stanojevic - Nevidljivi
wrote:
> Hi there,
>
> I'll just reply here, since it would be tiresome to answer to all of you
> separately.
>
> >>simpleinit demonstrates why sysvinit was created!
> >
> >I think you have this backwards, although i could be wrong, our simpleinit
> >setup was created after the sysvinit style was thought up.
>
> My point is. You are transferring all the boot process to /etc/init.d/rc
> script, which is way different to how sysvinit does it. Early unices did
> it just like sm does it now, an rc script. Almost as you would boot
> linux with init=/etc/init.d/rc ?!? [ lets forget the respawning aspect
> for simplicity :) ]

Here's a quick smgl init concepts overview that might allow you to parse
the code easier:

The init program stores the linked list of spawned services (see the
display-services command) fed to it via a /dev/initctl fifo using the
"need" command, which will "block" until the "need" is satisfied in
init's linked list record. It handles tty spawning and calls wait() on
zombied processes it inherits to reap them and handles ctrl-alt-del
logic. Everything else is very, very simply handled by /etc/init.d/rc,
but it's more than the BSD-style init you are referring to.

To get the system booted, you "need" the default runlevel and the
runlevel need logic goes down to the first runlevel since it's needed
first. Each runlevel script then "needs" everything within the runlevel
it represents that is enabled. It's actually quite elegant for handling
dependencies.

>
> It was written that we don't have to keep up with the bad practices of
> other unices, and so we went to simpleinit. But! sysvinit IS maintained,
> and it is maintained at least 30 years. Simpleinit died rather quickly,
> didn't it? If sysvinit was so bad, don't you thing other major
> distributions would leave it years ago?

Binary distros like to be 100% compatible with the status quo. Source
distros have a lot more freedom to move around and thus can be a little
more creative. Another major source distro, as was already mentioned,
doesn't use sysvinit, either, although that might be because they prefer
to write in Python rather than C.

>
> Also about dependices... I don't think it is really UNIXish to rely to
> much on the others. If the program needs ldap server up and running, is
> it so hard to script it in its startup script?

How do you do this in sysvinit generally?

> Moreover, numbering
> scheme user in sysvinit doesn't have to be unique. It is completely
> irrelevant will the sshd, or apache2 start first.

simpleinit doesn't enforce a consistent ordering because it doesn't
pre-flatten the dependency information. It's handled at run-time.
What's relevant is described in the script itself. Isn't better to
describe what you want rather than the way it will happen? That's
source code for you -- what you want rather than the exact way it will
happen.

> In such cases you can
> reuse these numbers over and over again (ie. S050sshd and S050apache2).

Yes, we're all (well at least I am) quite familiar with sysvinit.

> As for parallel script execution, I don't know much about it. I just
> know that smgl-0.9.4-test3 doesn't use it.

It's not enabled by default, but can be enabled by a one-line config
option in /etc/sysconfig/init. For multiprocessor systems, I always
turn it on because it is noticably faster to boot not to mention it's
always nice to know you're actually using the processors you paid for.
For single-processor systems it's not much of a gain except for filling
in little holes of emptiness here and there.

>
> >Let us draw a line between the init program (/sbin/init) and the
> >init scripts (/etc/init.d). In many respects the two are independent.
> >Lets not get confused between the sysvinit script style (symlink forest
> >with [SK]\d+name), and the actual sysvinit program which knows nothing
> >of this.
>
> This is a valid point. I don't like init.d scripts more than init itself.
>

I'll be considering the two together, since, while there is a
distinction, I think you were meaning to talk about entire init systems.

> The reason I picked on init first was that my network support is not
> brought up. So, off I went with:
> runlevel - but no such command ?
> vi /etc/inittab - and I was greeted with something unfamiliar, but ok
> vi /etc/init.d/rc - and there was the problem
>
> The problem is, to get the runlevel I am, I need to find it in
> /etc/sysconf/*, and I'm used to find it in inittab.

does "telinit runlevel" not work?

does /etc/sysconfig/init not tell you your default runlevel?

>
> Moreover. In sysvinit runelevels are completely separate, but in
> simpleinit you use them all, from 1st to 2nd, 3rd... which is strange.

I'm not sure what you mean here. telinit switch will let you change
runlevels. telinit help will give you more commands.

>
> >I do not think sysvinit scripting style lends itself well to automation
> >with user intervention, inter-script dependencies, both on bootup and on
> >shutdown, or handling parallel init script execution like our setup does.
>
> I thought of this distribution as returning decisions to the SA (which,
> by the way, increases complexity), not "users". I don't see the
> problem here. If an SA breaks init.d scripts, it's his/hers doing. With
> sysvinit SA gets the choice of what is started when, and as I've seen
> with simpleinit, simpleinit itself sorts what its starts when based on
> dependices. That sound more as loosing control than gaining it.

Runlevels still operate alphabetically when parallel init is disabled.
If you prefix all the init scripts with 00 or with z-00 you can move
them to wherever you want them.

If the init script is renamed and sorcery doesn't find it installed
again, sorcery will not install them by default during a rebuild.
Exceptions are for REQUIRED init scripts -- and these are only in the
init.d spell which is our specific init.d code.

If you desire, you can use sysvinit yourself and remove init.d and
simpleinit-msb from basesystem. Sorcery will not trample on your init
system outside of those two spells. Just use scribbler to copy the
basesystem spell to a local grimoire and edit it by hand -- you'll never
have to worry about sorcery messing with init scripts again (in theory,
it would be a definite bug otherwise).

>
> >Keep in mind that our setup requires very little modification to existing
> >sysvinit style init scripts. In many cases, ours are actually smaller
> >due to common code being factored into libraries.
>
> Yeah, that's the second problem. SysVinit executes subshells for any
> script, and therefore they are correctly written but in sgml there are a
> lot of errors, since you don't use subshells but source other scripts.
> Just for example:

We're bash people, we subshell only when needed (typically when we
desire scope enforcement) because forks are more expensive than for
example source or {; }.

>
> In /etc/inittab you set PATH:
> PATH = /sbin:/bin:/usr/sbin:/usr/bin
>
> This is then put in the environment for /etc/init.d/rc, BUT! in that
> script you reset it:
>
> PATH=/sbin:/bin
> also you set the variable RUNLEVELS_DIR
>
> then you source the /etc/sysconfig/init, and reset RUNLEVELS_DIR with
> the same value
>
> following that you source the /etc/init.d/sgml_functions and yet again
> reset PATH
>
> export PATH=/bin:/usr/bin:/sbin:/usr/sbin
>

Yeah, that might be cruft laying around from when it was first written.
We could easily clean those up, though. The paths aren't meant to be
edited by the SA, though. If you want to clean it up, we take patch
submissions well. That might make init's PATH editable easier. I might
add that PATH is actually hardcoded in most init systems, even sysvinit
last I checked, so it's really no different if you include that code to
be inside the init system proper.

> Now after that I stopped looking...
>
> I didn't even got to the network part which was the real problem for
> which I went to this hunt...

Mostly, I think you ran into an ISO bug and I'll note that we are still
pre-1.0 and thus don't expect people to be running source mage on
mission critical systems. In fact, I will disclaim the use of Source
Mage on mission-critical systems. Debian is for those. Anybody running
an OS on their mission-critical system must check all upgrades in a
redundant test framework anyways as a matter of sane policy. Nobody
does live upgrades to mission critical systems and stays employed for
long. This is especailly true of all source-based systems. The
increase in customization makes complexity too high for that type of
work.

>
> While I'm at it, I doubt I would put something like simpleinit at my
> production server... ever... I don't mind learning it, I don't mind
> learning anything, but this is, IMO, a wrong way to do it.

I'm running it on a number of production servers without problems. I am
the QA lead because we're not quite stabilized. We've undergone rapid
development recently and I took the role on to bring sanity to all the
recent infrastructure development. That being said, my preference is to
fix things the way they are rather than to rewrite things -- rewrites
don't tend to stabilize, despite the other gains that can be had.

>
> IMHO simpleinit was created because sysvinit was not understood at that
> time... It is reinventing the wheel in the bad way...

We understand sysvinit quite well. That's why we switched. We didn't
all sit around and twiddle our thumbs wishing we knew how sysvinit
worked. The main thing is: there is very little "order" to sysvinit
across systems. Sysvinit is not really standardized across distros and
there's really no simple init script installation mechanism.

Many upstream authors will even include init scripts designed for each
of the different binary distro vendors despite their use of sysvinit.
So really, there's not much to lose in rolling your own init system.
And if you do understand simpleinit as much as you do sysvinit,
modifying a sysvinit script for simpleinit can take a minute or two.

>
> That said, the newest Mac OS X - Tiger has created completely new bootup
> process called launchd...

Is this a suggestion? If it's as easy as simpleinit and has definite
tangible benefits, we could move to it. I doubt it though.

>
> - thank for all your replies -
> N::

Thanks for the feedback,

Seth


--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org

Attachment: pgp99rl4ikUwD.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page