Recursive disabling of services?
Hi,
I have service B dependent on service A and both instances are online. Then I run
# svcadm disable A
This results in the following log outputs.
[ Apr 20 22:25:00 Executing stop method ("/lib/svc/method/A stop") ]
[ Apr 20 22:25:01 Method"stop" exited with status 95 ]
[ Apr 20 22:25:01 Stopping because dependency activity requires stop. ]
[ Apr 20 22:25:01 Executing stop method ("/lib/svc/method/B stop") ]
[ Apr 20 22:26:40 Method"stop" exited with status 0 ]
Then service B is disabled successfully while service A ends up in the maintenance state.
Is this correct behaviour?
/Kevin
[765 byte] By [
kpmcnamee] at [2007-11-26 6:39:34]
# 1
I should also say that I am running Solaris 10 1/06 with the latest Recommended Patch Cluster./Kevin
# 2
Yes. "/lib/svc/method/A stop" exited with status 95, which svc.startd interprets as anerror, so it puts the service into maintenance. If the method successfully stops theservice, then it should exit with status 0.
# 3
But why does SMF try to stop service A and then try to stop its dependency?
Of course A will fail to shutdown in that situation.
Wouldn't it make more sense for SMF to stop B and then stop A (since it seems to realise there is a dependency)?
Is this a bug in SMF?
Regards,
Kevin
# 4
If B depends on A, then svc.startd will only stop B when A stops if the dependency
specifies "restart_on=restart" or "restart_on=refresh". That means that B can't be trusted
after A has been restarted or its configuration has changed.
If A cannot be stopped while or after B is being stopped, then A & B must have some
special relationship and it may make more sense to manage them as a single service.
SMF could stop B before A, but this situation would still occur if A stopped unexpectedly
(like it dumped core). Since services should be robust against that situation, it's not clear
that it's worth our time making SMF coddle less robust services.
# 5
What I need if to stop B before A.
I have been testing how this behaves during a reboot (init 6) and the same thing occurs, i.e. SMF stops A and then stops B.
In the old rc scripts this was not a problem. Does SMF shutdown processes in the reverse order during shutdown?
Does it actually wait for its dependencies during shutdown?
Regards,
Kevin
# 6
Yes, svc.startd stops services in reverse dependency order on shutdown.
# 7
I have tested this and can state that while SVC does recognise that dependencies should be shutdown when a service is disabled, it shuts down the parent service BEFORE it tries to shut down its dependencies. Can you confirm this?
# 8
Correct. When the system is shutting down, svc.startd stops services inreverse-dependency order. When a single service is stopped, stops are initiated forservices which depend on that service and have requested to be stopped in that case.
# 9
Sorry, I have made a classic typo.
What I meant was that SMF shuts down the parent service BEFORE it tries to shut down its dependents. This equates to stopping a database before stopping the application server that depends on it.
In the test I added the following code to the stop method of the database:
while [ -n "`svcs -H -o state app_server | grep online`" ]; do
sleep 5
done
When I tried to shutdown the database, svc did not stop the app_server first as one would have expected. As a result the database shutdown hung in the while loop.
To create the desired behaviour I instead added the following to the stop method of the database:
if [ `svcs | grep -c app_server` != 0 ]; then
svcadm disable -st app_server
fi
# 10
I understood what you meant. You're asking for SMF to distinguish between the case
where the user has requested that a service be stopped and the case where the service
has stopped on its own. You want SMF to stop dependents first in the former case, even
though we can't in the latter. Please file a bug at bugs.opensolaris.org .
# 11
I have reported a bug with the heading"Recursive disabling of services at user request fails"Thanks for your help.
# 12
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6422793
