Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

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