On Thu, 05 Aug, 2010 at 14:19:49 +0800, west alto wrote:
I try playing on the INIT INFO part it does not work for the stop sequence order:
Yes. This is as I said, and the explanation is indeed found in the manpage.
man insserv says:
Please note, that the Required-Stop, Should-Stop, X-Stop-After, and Default-Stop are ignored in SuSE Linux, because the SuSE boot script concept uses a differential link scheme (see init.d(7)).
When I first saw this I was pretty shocked... A short explanation of the 'differential link scheme' is something like: --- A service 'foo' is set to be running in both runlevels X and Y. When switching runlevel from X -> Y (or Y -> X) then 'foo' is left running, as opposed to being stopped (because of leaving a runlevel) and then started again (because of entering a runlevel). --- This is all well and good, but the problem is that service *dependencies* are a completely different consideration. The upshot is, that one cannot dictate 'stop dependencies' using the LSB headers (INIT INFO) of the init scripts in SLES10* someone CMIIW?
What part in the sles configuration dictates about the differential link scheme?
The problem is not with the differential scheme itself, but rather that stop dependencies are ignored.
On Wed, Aug 4, 2010 at 5:24 PM, Jon Clausen <jon@ymmv.dk> wrote:
On Wed, 04 Aug, 2010 at 16:59:21 +0800, west alto wrote:
Thanks, Jon.
How does sles set the sequence?
K21foo K20bar
I don't know how the order is determined, except that on SLES10 it is *not* derived from the *-stop dependencies of the LSB headers.
This *should* have been: "I don't know how the order is determined in SLES10, except that it is *not* derived from *-stop dependencies of the LSB headers." I observed that the stop-links would sometimes be rearranged, if the start-dependencies were changed. In my situation it was not possible to find a set of start deps, that would result in both correct ordering on *both* start and stop. Probably insserv has some internal logic about how to order stop links. As I remember it *was* pretty consistent about the (wrong) order generated. Incidentally the behaviour was changed in SLES11. In the end I think you have more or less these choices: 1: If the error is 'cosmetic' (as in "it won't break your SAN stuff") - you *could* choose to ignore it altogether. 2: Evaluate the feasibility of upgrading to SLES11, where the underlying problem is 'solved'. 3: If you can't upgrade to 11, and the error may result in potential breakage of your storage - then the only way *I* can think of is what I said earlier: Make a separate init script, that has no other active function than to stop one of the services. Then experiment with the start deps of that script until you find a combination that makes insserv generate the correct stop sequence. hth /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org