[opensuse] runlevel daemon startup shutdown sequence
Hi Gurus, How can i adjust the shutdown or startup priority sles10sp3? Here what is inside my: /etc/init.d/rc3.d K21PowerPath K21naviagent S01PowerPath S01naviagent /etc/sysconfig/boot RUN_PARALLEL=yes When it enters the runlevel 3 naviagent starts first then followed by PowerPath. When it leaves the runlevel 3 PowerPath stops first (which gives an error that naviagent still running), then stops other daemon, then stops naviagent Is there a way to reverse the shutdown so the naviagent will stop first followed by PowerPath. I change K21naviagent to K20naviagent in /etc/init.d/rc3.d and RUN_PARALLEL=no in /etc/sysconfig/boot but still PowerPath shutdown first then naviagent. Please help. Thanks, West -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 04 Aug, 2010 at 15:55:28 +0800, west alto wrote:
Hi Gurus,
How can i adjust the shutdown or startup priority sles10sp3?
On SLES10* shutdown sequence is not easily tweaked. The order of startup/shutdown is defined using dependencies specified in the LSB headers of the init scripts themselves. Unfortunately, however, the *-stop dependencies are ignored on SLE*10*
Here what is inside my:
/etc/init.d/rc3.d K21PowerPath K21naviagent S01PowerPath S01naviagent
/etc/sysconfig/boot RUN_PARALLEL=yes
When it enters the runlevel 3 naviagent starts first then followed by PowerPath. When it leaves the runlevel 3 PowerPath stops first (which gives an error that naviagent still running), then stops other daemon, then stops naviagent
I'm not familiar with either naviagent or PowerPath (a quick search indicates it's some SAN management thingy?) but I'm guessing it's fairly important that they get shut down in the proper sequence.
Is there a way to reverse the shutdown so the naviagent will stop first followed by PowerPath.
I had a similar situation with NSS storage on iSCSI a while back. In short, the system would consistently shut down iSCSI before NSS was unmounted. To work around the issue, I ended up creating a dedicated 'unmount NSS' init script which had the following behaviour: @start: do nothing @stop: unmount the pertinent NSS volumes Then I experimented with the 'start' dependencies of that script, until chkconfig would place it at the correct point in the stop sequence.
I change K21naviagent to K20naviagent in /etc/init.d/rc3.d and RUN_PARALLEL=no in /etc/sysconfig/boot but still PowerPath shutdown first then naviagent.
RUN_PARALLEL=no is probably a good idea. It will certainly make things more predictable. Manually changing the links OTOH is not a good idea. The next time chkconfig is invoked, it *will* change the links back to whatever it deems correct. hth /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Jon Clausen (jon@ymmv.dk) [20100804 10:39]:
Manually changing the links OTOH is not a good idea. The next time chkconfig is invoked, it *will* change the links back to whatever it deems correct.
It's not chkconfig that changes it but rather insserv. Chkconfig is mostly just a wrapper to make it easier for folks used to RedHat. And insserv is SuSE's implementation of an LSB conforming init script handler. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 04 Aug, 2010 at 10:50:22 +0200, Philipp Thomas wrote:
* Jon Clausen (jon@ymmv.dk) [20100804 10:39]:
Manually changing the links OTOH is not a good idea. The next time chkconfig is invoked, it *will* change the links back to whatever it deems correct.
It's not chkconfig that changes it but rather insserv. Chkconfig is mostly just a wrapper to make it easier for folks used to RedHat. And insserv is SuSE's implementation of an LSB conforming init script handler.
hmm, well, yeah... you're right about that :P But the effect is the same regardless, yes? /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thanks, Jon. How does sles set the sequence? K21foo K20bar Where is the settings that drive the sequence order of startup and shutdown of daemon? Thanks, West On Wed, Aug 4, 2010 at 4:39 PM, Jon Clausen <jon@ymmv.dk> wrote:
On Wed, 04 Aug, 2010 at 15:55:28 +0800, west alto wrote:
Hi Gurus,
How can i adjust the shutdown or startup priority sles10sp3?
On SLES10* shutdown sequence is not easily tweaked.
The order of startup/shutdown is defined using dependencies specified in the LSB headers of the init scripts themselves. Unfortunately, however, the *-stop dependencies are ignored on SLE*10*
Here what is inside my:
/etc/init.d/rc3.d K21PowerPath K21naviagent S01PowerPath S01naviagent
/etc/sysconfig/boot RUN_PARALLEL=yes
When it enters the runlevel 3 naviagent starts first then followed by PowerPath. When it leaves the runlevel 3 PowerPath stops first (which gives an error that naviagent still running), then stops other daemon, then stops naviagent
I'm not familiar with either naviagent or PowerPath (a quick search indicates it's some SAN management thingy?) but I'm guessing it's fairly important that they get shut down in the proper sequence.
Is there a way to reverse the shutdown so the naviagent will stop first followed by PowerPath.
I had a similar situation with NSS storage on iSCSI a while back. In short, the system would consistently shut down iSCSI before NSS was unmounted.
To work around the issue, I ended up creating a dedicated 'unmount NSS' init script which had the following behaviour:
@start: do nothing @stop: unmount the pertinent NSS volumes
Then I experimented with the 'start' dependencies of that script, until chkconfig would place it at the correct point in the stop sequence.
I change K21naviagent to K20naviagent in /etc/init.d/rc3.d and RUN_PARALLEL=no in /etc/sysconfig/boot but still PowerPath shutdown first then naviagent.
RUN_PARALLEL=no is probably a good idea. It will certainly make things more predictable.
Manually changing the links OTOH is not a good idea. The next time chkconfig is invoked, it *will* change the links back to whatever it deems correct.
hth /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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.
Where is the settings that drive the sequence order of startup and shutdown of daemon?
In the init scripts themselves. The information is kept in the comments in the top of the script, between ### BEGIN INIT INFO and ### END INIT INFO /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I try playing on the INIT INFO part it does not work for the stop sequence order: man insserv says: and calculating the dependencies between all scripts. 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)). The optional X-Start-Before keyword implies that the script using this keyword should be started before the specified service names. This implies that those services now depend on the specifying script. With known dependencies and runlevel(s) insserv sets and reorders the corresponding symbolic links of the concerned runlevels directories (see init.d(7)). Known runlevels are: What part in the sles configuration dictates about the differential link scheme? 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.
Where is the settings that drive the sequence order of startup and shutdown of daemon?
In the init scripts themselves.
The information is kept in the comments in the top of the script, between
### BEGIN INIT INFO
and
### END INIT INFO
/jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-05 09:37, Jon Clausen wrote:
On Thu, 05 Aug, 2010 at 14:19:49 +0800, west alto wrote:
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.
I think it is done in the reverse order that was used for start. I don't know about SLES, but I can give you a sample for openSUSE. There was a problem with the clock setup sequence in one script, so what they did was split the handling in two scripts in oS 11.0: boot.clock start sequence boot.getclock stop sequence However, I notice that oS 11.2 does not have boot.getclock, so perhaps in 11.2 they have the stop sequence under control. In any case, you could use the same trick they used in 11.0 for SLES.
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.
Exactly. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxaoqAACgkQU92UU+smfQW9PQCfa9C0agRfncw7ulTzvTZ0/bXf IhQAnA68ve5bc9JKYnim7e3AE9Ix9mB1 =EL/U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 05 Aug, 2010 at 13:38:08 +0200, Carlos E. R. wrote:
On 2010-08-05 09:37, Jon Clausen wrote:
Probably insserv has some internal logic about how to order stop links. As I remember it *was* pretty consistent about the (wrong) order generated.
I think it is done in the reverse order that was used for start.
Actually I don't think it's quite that simple, but I no longer have access to the system in question (or any SLES10s for that matter) so I can't test/verify
I don't know about SLES, but I can give you a sample for openSUSE. There was a problem with the clock setup sequence in one script, so what they did was split the handling in two scripts in oS 11.0:
boot.clock start sequence boot.getclock stop sequence
However, I notice that oS 11.2 does not have boot.getclock, so perhaps in 11.2 they have the stop sequence under control.
Hm. I never noticed that...
In any case, you could use the same trick they used in 11.0 for SLES.
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.
Exactly.
Interesting. When I finally realized what the problem was, I came up with the above workaround on my own. It's kinda funny that the very same thing was in use on systems that I installed/used since then... But of course, none of *those* systems ever had configurations where the networked storage had to be unmounted before the underlying services were stopped... /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Carlos E. R. -
Jon Clausen -
Philipp Thomas -
west alto