sysvinit: rc vs. r2d2 bahavior
Martin Schulze
> I had a deep look into the rc scripts from sysvinit and file-rc as
> well as the r2d2 script by Winfried Trümper.
>
> This is what rc (sysvinit) does and file-rc should do (I think, that
> there is some bug):
>
> 1. Run all K??-scripts in the new runlevel with the parameter "stop"
> except when starting up (prevlevel==N).
> 2. Run all S??-scripts in the new runlevel which are not in
> prevlevel as S??-scripts or which are also K??-scripts in the new
> runlevel. When going to runlevel 0 or 6, use parameter "stop"
> otherwise "start".
>
> For all this use the ascending order of the number of the scripts.
>
> This seems to be historical normal behavior of rc, but it's not too
> intuitive...
>
> Instead of this here's what r2d2 does:
>
> 1. Run all K??-scripts in new runlevel, which are not K??-scripts in
> the prevlevel. Do this in _descending_ order of the scripts
> (stop first, what is started last). Use "stop" as parameter.
> 2. Run all S??-scripts in new runlevel, which are not S??-scripts in
> the prevlevel. Do this in _ascending_ order of the scripts. Use
> "start" as parameter.
>
>
> So my question is the following: Why do we keep this non intuitive
> behavior of sysvinit and file-rc instead of intuitive behavior of
> r2d2?
Historical?
In fact, I'd appreciate if you could package up r2d2 as 2nd alternative,
and include proper conversion utilities. This is the *only* way to
show people that a) there is a different way and b) it could be more
useful than the conservative one.
This is my experience with file-rc.
Finally I don't think that either file-rc or r2d2 will be able to
replace the conservative rc mechanism that sysvinit uses. The
reason is quite simple, it is a proper method that is used upon
several flavours of of Linux like operating systems, including
System V Unix derivates. Linux should not become incompatible to
them - it should however present new ideas and new techniques but
stay compatible.
Regards,
Joey
--
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miquel van Smoorenburg
>> I had a deep look into the rc scripts from sysvinit and file-rc as
>> well as the r2d2 script by Winfried Trümper.
>>
>>
>> 1. Run all K??-scripts in new runlevel, which are not K??-scripts in
>> the prevlevel. Do this in _descending_ order of the scripts
>> (stop first, what is started last). Use "stop" as parameter.
>> 2. Run all S??-scripts in new runlevel, which are not S??-scripts in
>> the prevlevel. Do this in _ascending_ order of the scripts. Use
>> "start" as parameter.
Oh this will break existing setups _horribly_.
>> So my question is the following: Why do we keep this non intuitive
>> behavior of sysvinit and file-rc instead of intuitive behavior of
>> r2d2?
Because it will break your system?
Really I've explained the backgrounds of the init system a few times here
and a few times in private email. I'm not going to do it again unless
someone puts it in a FAQ somewhere.
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
Martin Schulze
> BTW: neither rc from sysvinit nor from file-rc behave exactly in the
> way Debian policy 3.3.1 describes (r2d2 also doesn't ;-).
Can you elaborate on this please?
Regards,
Joey
--
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi
Please always Cc to me when replying to me on the lists.
Roland Rosenfeld
> > BTW: neither rc from sysvinit nor from file-rc behave exactly in the
> > way Debian policy 3.3.1 describes (r2d2 also doesn't ;-).
> Can you elaborate on this please?
The policy tells us:
When `init' changes runlevel first the targets of the links whose
names starting with a `K' are executed, each with the single
argument `stop', followed by the scripts prefixed with an `S',
each with the single argument `start'.
But this is what rc from sysvinit (and hopefully the rc from your
newly patched file-rc, too) does:
1. Run all K??-scripts in the new runlevel with the parameter "stop"
except when starting up (prevlevel==N).
2. Run all S??-scripts in the new runlevel which are not in
prevlevel as S??-scripts or which are also K??-scripts in the new
runlevel. When going to runlevel 0 or 6, use parameter "stop"
otherwise "start".
I cannot find anything about the "prevelvel" exception in the policy
and I didn't find a word about running all scripts with parameter
"stop" when going to runlevel 0 or 6 there.
So we have three different variants of the behavior now:
a) the one from the policy: this is very simple, but when you have two
nearly identical runlevels with only some small difference, this
will imply that rc tries to start all daemons, which results in
problems when some init.d script doesn't check whether it is run
for the second time with "start" now.
b) the one implemented in sysvinit rc: this gets rid of the multiple
running with "start" by checking the previous level. But this is
only implemented for "start" not for "stop" (why?) and then there's
the additional rule for changing the parameter to "stop" when going
to runlevel 0 or 6 (which seems to be a bug for me, because when I
want "stop" as the parameter I will name the link K?? instead of
S??).
c) the one implemented in r2d2: this is completely logical, but quite
different from the above ones. It's only fault seems to be, that it
came too late...
As you can see b) doesn't implement a). So where's the argument that
doesn't allow me to replace b) by c), which also doesn't implement a)?
Tschoeeee
Roland
--
* rol...@spinnaker.rhein.de * http://www.rhein.de/~roland/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Paul Slootman
At work we use Solaris 2.5. We have changed the rc stuff so that each
higher runlevel _adds_ things only. I.e., when increasing the runlevel,
only the start scripts of the higher runlevels are run.
E.g. in runlevel 1 there are the very basic things running.
When going to runlevel 2 from 1, _only_ the S?? scripts in rc2.d are run.
When going to rl 3 from 2, _only_ the S?? scripts in rc3.d are run.
If you go from rl 1 directly to 3, first the S?? scripts in rc2.d are
run, followed by the S?? scripts in rc3.d.
When going from rl3 to rl2, the K?? scripts in rc3.d (not rc2.d!) are
run. When going from rl3 directly to rl1, first the K?? scripts in rc3.d
are run, followed by the rl2 K?? scripts.
This is something that's quite easy to get used to, and works IMHO
more intuitively than the "traditional" rc systems. However, we can
do this only because we integrate _everything_ ourselves; it's not
really something that you can decide on a whim to do. Debian should
stick to what it has, IMHO.
Paul Slootman
--
home: pa...@wurtel.demon.nl | work: pa...@murphy.nl | debian: pa...@debian.org
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
Roland Rosenfeld
> > But this is what rc from sysvinit (and hopefully the rc from your
> > newly patched file-rc, too) does:
> >
> > 1. Run all K??-scripts in the new runlevel with the parameter "stop"
> > except when starting up (prevlevel==N).
> > 2. Run all S??-scripts in the new runlevel which are not in
> > prevlevel as S??-scripts or which are also K??-scripts in the new
> > runlevel. When going to runlevel 0 or 6, use parameter "stop"
> > otherwise "start".
> > I cannot find anything about the "prevelvel" exception in the policy
> > and I didn't find a word about running all scripts with parameter
> > "stop" when going to runlevel 0 or 6 there.
> The stop/start switch is IMHO bogus, and blatantly violates the rule
> of least surprise..
This is what I see, too. But it is implemented, so I fear that it was
intensional. Maybe someone knows what the intension was? Otherwise we
make break something be removing this exception...
> As far as the 'prevlevel' exception, its not needed, it makes things
> more complex, and one could argue that it could break some cases..
> (IE someone purposely shuts something down, and then later changes
> runlevel, the runlevel change should restart it)
This is what _you_ expect. I expect only those scripts to be started
which _need_ to be started. I fear that I'm the only person who really
uses different runlevels so I will give you an example where I use
this for:
Sometimes it may be a good idea to unload the ISDN modules (because of
installing newer ones or because of trouble on the S0 bus). For this I
need to switch of mgetty and vboxgetty which work on some ttyI*
devices (otherwise it isn't possible to unload the modules). The
easiest way to realize this is to use two different runlevels which
differ in the start of the gettys above and which start/stop the
isdnutils package (isdnlog, isdnctrl,...).
For this only one or two scripts in /etc/init.d have to be run with
start/stop (more isn't useful), but when I do this in the way the
policy requests, many scripts are run with start, with costs time but
doesn't make much sense to me.
So I like the way, sysvinit rc and file-rc work at the moment and I
even like more the way r2d2 works.
BTW: Nobody seems to have a problem with the actual behavior, so I
don't see, why we should make it worse. Instead we should simply
change the policy...
> > c) the one implemented in r2d2: this is completely logical, but
> > quite different from the above ones. It's only fault seems to
> > be, that it came too late...
> Logical but completely different is nice, but would be next to
> impossible to make the change over, and for how much benefit?
The benefit is, that everybody can simply understand what's going on.
As far as I can see, most people use sysinit-rc by simply running
update-rc.d with the default argument, hoping that everything will
work without problems. Nearly nobody seems to know what this really
means. r2d2 with it's simple runlevel.conf configuration file makes
everything much easier. You can see with only one look, which daemons
are running in which runlevel and you can see without problems in
which order the daemons are started. They are stopped in the reverse
order which seems to be the intuitive way.
I think that Debian introduced some interesting new ideas to the
system administration, which make life easier. So I don't see, why we
should stay on old ideas here, where better solutions are possible.
> > As you can see b) doesn't implement a). So where's the argument
> > that doesn't allow me to replace b) by c), which also doesn't
> > implement a)?
> Someone needs to file a bug against sysvinit, sigh, this could be
> interesting, anyone else care to file?
I prefer to file a bug against policy ;-)
Ciao
Roland
--
* rol...@spinnaker.rhein.de * http://www.rhein.de/~roland/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Miquel van Smoorenburg
Roland Rosenfeld <rol...@spinnaker.rhein.de> wrote:
>The policy tells us:
>
> When `init' changes runlevel first the targets of the links whose
> names starting with a `K' are executed, each with the single
> argument `stop', followed by the scripts prefixed with an `S',
> each with the single argument `start'.
Yes, that is correct. That is the short description.
>But this is what rc from sysvinit (and hopefully the rc from your
>newly patched file-rc, too) does:
>
> 1. Run all K??-scripts in the new runlevel with the parameter "stop"
> except when starting up (prevlevel==N).
Ofcourse when prevlevel == N the K scripts do not get run - but that
is not obvious from the policy document. I does make a lot of sense.
> 2. Run all S??-scripts in the new runlevel which are not in
> prevlevel as S??-scripts or which are also K??-scripts in the new
> runlevel.
This is merely an optimization. When you go from runlevel 2 to runlevel 3,
and the squid proxy runs in both levels, you don't want to have it
stopped and started again ..
> When going to runlevel 0 or 6, use parameter "stop"
> otherwise "start".
This doesn't make much sense, and I have been critisized for implementing it
this way.
The thing was, I needed a way to run "stop" scripts for the halt/reboot
procedures AFTER /etc/rc6.d/K99xxxxx. Since most of those scripts
didn't look at $1 after all, I just used /etc/rc6.d/SXXxxxx. Then some
scripts appeared that did look at $1. Now the easiest and most compatible
way to fix this was to just say "OK, Sxx scripts in runlevel 0 and 6
are called with the "stop" argument".
>I cannot find anything about the "prevelvel" exception in the policy
That should really be in there.
>and I didn't find a word about running all scripts with parameter
>"stop" when going to runlevel 0 or 6 there.
If we decide we do not want to do that, we should allow runlevel 0 and
6 to have K scripts with numbers > 99. Say K100 .. K199 or so. Then
migrate the Sxx scripts to K1xx.
Not in "slink" though, since all packages that install links in
/etc/rc{0.6}.d/Sxx should be updated at the same time and their postinst
should move the Sxx link to K1xx etc etc.
>b) the one implemented in sysvinit rc: this gets rid of the multiple
> running with "start" by checking the previous level. But this is
> only implemented for "start" not for "stop" (why?)
If there is a K link present, the script will be stopped. If there also
is a S link present, it will be started _again_. This is intentional -
if the maintainer of the package doesn't want the package to be stopped
and started, he/she can just not install the K link. In fact the K
link is not installed in runlevels 2, 3, 4 and 5 by default by update-rc.d
So it is the other way around - see it as a facility a package can
use to have the daemon or whatever stop and restart on a runlevel change.
> and then there's
> the additional rule for changing the parameter to "stop" when going
> to runlevel 0 or 6 (which seems to be a bug for me, because when I
> want "stop" as the parameter I will name the link K?? instead of
> S??).
As I said, the problem was that I needed to add a bunch of scripts
after K99, and levels > K99 weren't defined nor supported by update-rc.d.
I didn't feel like fixing update-rc.d and doing an NMU for dpkg at the
time, because dpkg is a package I rather not fool around with.
>c) the one implemented in r2d2: this is completely logical, but quite
> different from the above ones. It's only fault seems to be, that it
> came too late...
Also, running the K scripts in reverse order is logical but incompatible
with any package out there that depends on the order it's stop script(s)
is/are run in. And it's incompatible with most other Unices.
>As you can see b) doesn't implement a). So where's the argument that
>doesn't allow me to replace b) by c), which also doesn't implement a)?
b) is the defacto standard. a) is an attempt to describe it.
You need to follow b) and/or fix a) (and perhaps even fix b) if needed).
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
Miquel van Smoorenburg
Miquel van Smoorenburg <miq...@cistron.nl> wrote:
>> 1. Run all K??-scripts in the new runlevel with the parameter "stop"
>> except when starting up (prevlevel==N).
>
>Ofcourse when prevlevel == N the K scripts do not get run - but that
>is not obvious from the policy document. I does make a lot of sense.
Now that I read my own message again. it doesn't.
>> 2. Run all S??-scripts in the new runlevel which are not in
>> prevlevel as S??-scripts or which are also K??-scripts in the new
>> runlevel.
>
>This is merely an optimization. When you go from runlevel 2 to runlevel 3,
>and the squid proxy runs in both levels, you don't want to have it
>stopped and started again ..
And the same goes for this sentence.
I'll write up a more complete explanation and put it in /usr/doc/sysvinit,
at least it is then documented what sysvinit currently does and _why_
Thanks for your lengthy explanation, it made me think about things
I thought I was sure about but am not anymore.
Miquel van Smoorenburg
now. I think it is accurate. Note that this is NOT what should be in
the policy document, I do not claim this is the right way to do things,
it's simply a description of the current system.
I hope you don't expect this document to be free of speling mistaeks and
gramatical errors, because it isn't. Come on it's almost newyears eve..
Order of scripts run in /etc/rc?.d
==================================
0. Overview.
All scripts executed by the init system are located in /etc/init.d.
The directories /etc/rc?.d (? = S, 0 .. 6) contain relative links to
those scripts. These links are named S<2-digit-number><original-name>
or K<2-digit-number><original-name>.
If a scripts has the ".sh" suffix it is a bourne shell script and
MAY be handled in an optimized manner. The behaviour of executing the
script in an optimized way will not differ in any way from it being
forked and executed in the regular way.
The following runlevels are defined:
N System bootup (NONE).
S Single user mode (not to be switched to directly)
0 halt
1 single user mode
2 .. 5 multi user mode
6 reboot
1. Boot.
When the systems boots, the /etc/init.d/rcS script is executed. It
in turn executes all the S* scripts in /etc/rcS.d in alphabetical
(and thus numerical) order. The first argument passed to the
executed scripts is "start". The runlevel at this point is "N" (none).
Only things that need to be run once to get the system in a consistent
state are to be run. The rcS.d directory is NOT ment to replace rc.local.
One should not start daemons in this runlevel unless absolutely
nessecary. Eg, NFS might need the portmapper, so it is OK to start it
early in the bootprocess. But this is not the time to start the
squid proxy server.
2. Going multiuser.
After the rcS.d scripts have been executed, init switches to the
default runlevel as specified in /etc/inittab, usually "2".
Init then executes the /etc/init.d/rc script which takes care of
starting the services in /etc/rc2.d.
Because the previous runlevel is "N" (none) the /etc/rc2.d/KXXxxxx
scripts will NOT be executed - there is nothing to stop yet,
the system is busy coming up.
If for example there is a service that wants to run in runlevel 4
and ONLY in that level, it will place a KXXxxxx script in
/etc/rc{2,3,5}.d to stop the service when switching out of runlevel 4.
We do not need to run that script at this point.
The /etc.rc2.d/SXXxxxx scripts will be executed in alphabetical
order, with the first argument set to "start".
3. Switching runlevels.
When one switches from (for example) runlevel 2 to runlevel 3,
/etc/init.d/rc will first execute in alphabetical order all K
scripts for runlevel 3 (/etc/rc3.d/KXXxxxx) with as first argument
"stop" and then all S scripts for runlevel 3 (/etc/rc3.d/SXXxxxx)
with as first argument "start".
As an optimalization, a check is made for each "service" to see if
it was already running in the previous runlevel. If it was, and there
is no K (stop) script present for it in the new runlevel, there is
no need to start it a second time so that will not be done.
On the other hand, if there was a K script present, it is assumed the
service was stopped on purpose first and so needs to be restarted.
We MIGHT make the same optimization for stop scripts as well-
if no S script was present in the previous runlevel, we can assume
that service was not running and we don't need to stop it either.
In that case we can remove the "coming from level N" special case
mentioned above in 2). But right now that has not been implemented.
4. Single user mode.
Switching to single user mode is done by switching to runlevel 1.
That will cause all services to be stopped (assuming they all have
a K script in /etc/rc1.d). The runlevel 1 scripts will then switch
to runlevel "S" which has no scripts - all it does is spawn
a shell directly on /dev/console for maintenance.
5. Halt/reboot
Going to runlevel 0 or 6 will cause the system to be halted or rebooted,
respectively. For example, if we go to runlevel 6 (reboot) first
all /etc/rc6.d/KXXxxxx scripts will be executed alphabetically with
"stop" as the first argument.
Then the /etc/rc6.d/SXXxxxx scripts will be executed alphabetically
with "stop" as the first argument as well. The reason is that there
is nothing to start anymore at this point - all scripts that are
run are ment to bring the system down.
In the future, the /etc/rc6.d/SXXxxxx scripts MIGHT be moved to
/etc/rc6.d/K1XXxxxx for clearity.
Robert Woodcock
>This doesn't make much sense, and I have been critisized for implementing it
>this way.
>
>The thing was, I needed a way to run "stop" scripts for the halt/reboot
>procedures AFTER /etc/rc6.d/K99xxxxx. Since most of those scripts
>didn't look at $1 after all, I just used /etc/rc6.d/SXXxxxx. Then some
>scripts appeared that did look at $1. Now the easiest and most compatible
>way to fix this was to just say "OK, Sxx scripts in runlevel 0 and 6
>are called with the "stop" argument".
There were SXXxxxx scripts in runlevels 0 and 6 that looked at $1? What
are these SXXxxx scripts doing (I can't see why they'd be in any extraneous
package), and why hasn't anyone filed bugs against them?
The entire runlevel thing should be completely arbitrary, there should
be nothing special about runlevels 0 or 6 (Debian defaults aside).
Let's fix the packages instead of breaking the arbitration.
--
Robert Woodcock - r...@debian.org
"Unix and C are the ultimate computer viruses" -- Richard Gabriel
Miquel van Smoorenburg
Robert Woodcock <r...@debian.org> wrote:
>There were SXXxxxx scripts in runlevels 0 and 6 that looked at $1? What
>are these SXXxxx scripts doing (I can't see why they'd be in any extraneous
>package), and why hasn't anyone filed bugs against them?
Well most scripts look at $1. For example, "urandom" (needs to know
whether to load or save state) and "mdutils". Both can be called from
/etc/rcS.d as well as /etc/rc6.d/Sxxx
In fact you might say that /etc/rc6.d/Sxxx is the complement of /etc/rcS.d
>The entire runlevel thing should be completely arbitrary, there should
>be nothing special about runlevels 0 or 6 (Debian defaults aside).
>Let's fix the packages instead of breaking the arbitration.
Well we need to do both if everyone is so upset about this (though
I still can't quite see why). But not in slink. In potato, perhaps.
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
Robert Woodcock
>In fact you might say that /etc/rc6.d/Sxxx is the complement of /etc/rcS.d
We both agree that the current purpose of /etc/rc6.d/S* is not to start
anything. I just think it's a hack to hard-code the purpose of a runlevel
like that.
I also think it's a bug in sysvinit and mdutils (raidtools too?) that
the urandom and mdutils (raid too?) kill scripts are run from a S*
script.
I understand your rationale for doing it this way, but the numbers should
have a purpose, and reorganizing them might be a worthy goal. On my system I
don't have anything after K91 (WHY does inn need to stop so late? apache is
even worse - it stops after sysklogd!) so unless something is using K95
there's enough reorganization room.
[cue the subliminal chanting for run-scripts, which can end all this number
horror, assuming I can ever finish it]
>Well we need to do both if everyone is so upset about this (though
>I still can't quite see why). But not in slink. In potato, perhaps.
Of course.
--
Robert Woodcock - r...@debian.org
"Unix and C are the ultimate computer viruses" -- Richard Gabriel
Andrew Pimlott
> okay, i just typed this up to show and explain what sysvinit does right
> now.
I've been following this thread with interest, and I wish to express
gratitude for elucidating a somewhat blurry area. May I suggest that, to
make this document complete, you mention the role of the /etc/rc.boot
directory, and perhaps also /etc/rc, /etc/rcS, and /etc/inittab? (By the
way, history aside, don't /etc/rc and /etc/rcS belong in /sbin instead?)
Thanks,
Andrew