Post by Dragan Stanojevic - NevidljiviHi there,
I'll just reply here, since it would be tiresome to answer to all of you
separately.
Post by AndrewPost by Dragan Stanojevic - Nevidljivisimpleinit 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.
Post by Dragan Stanojevic - NevidljiviIt 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.
Post by Dragan Stanojevic - NevidljiviAlso 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?
Post by Dragan Stanojevic - NevidljiviMoreover, 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.
Post by Dragan Stanojevic - NevidljiviIn 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.
Post by Dragan Stanojevic - NevidljiviAs 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.
Post by Dragan Stanojevic - NevidljiviPost by AndrewLet 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.
Post by Dragan Stanojevic - NevidljiviThe reason I picked on init first was that my network support is not
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?
Post by Dragan Stanojevic - NevidljiviMoreover. 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.
Post by Dragan Stanojevic - NevidljiviPost by AndrewI 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).
Post by Dragan Stanojevic - NevidljiviPost by AndrewKeep 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.
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 {; }.
Post by Dragan Stanojevic - NevidljiviPATH = /sbin:/bin:/usr/sbin:/usr/bin
This is then put in the environment for /etc/init.d/rc, BUT! in that
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.
Post by Dragan Stanojevic - NevidljiviNow 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.
Post by Dragan Stanojevic - NevidljiviWhile 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.
Post by Dragan Stanojevic - NevidljiviIMHO 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.
Post by Dragan Stanojevic - NevidljiviThat 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.
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