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: Dragan Stanojevic - Nevidljivi <invisible AT hidden-city.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Why simpleinit-msb ?
  • Date: Wed, 15 Jun 2005 15:44:49 +0200

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 :) ]

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?

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? Moreover, numbering scheme user in sysvinit doesn't have to be unique. It is completely irrelevant will the sshd, or apache2 start first. In such cases you can reuse these numbers over and over again (ie. S050sshd and S050apache2).
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.

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.

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.

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

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.

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:

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

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...

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.

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

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

- thank for all your replies -
N::

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.24.

Top of Page