I have created a transient SMF service which is dependent on a milestone "multi-user" now if I reboot the system it works fine but if I use "*shutdown -i6 -g5 -y*" to do a greaceful shutdown, sparc V240 system hangs.The OS version I am using is Solaris 10 update 5. I tried to find out the cause through logging in the system through ssh as it was working even after giving the shutdown command. When I did "*svcs -a | grep <my service>*", I am able to see my service online.As soon as I disabled it the shutdown which was hanged is resumed. I have to use dependent tag in my manifest file as the dependency tag is not starting my service at a particular milestone using the "*boot -m milestone=multi-user*" from ok prompt. My question : Is SMF framework wont issue any command to stop the service in graceful shutdown ? Is it just stops the milestone and rest is taken care by order of dependency of services ? What happen if a service is isolated ( no dependent or dependency in manifest file).
I have seen the output of "*echo ::startd_log | mdb -p `pgrep startd`*" It is showing the following logs but doesnt make any sense to me: Jun 9 20:28:41/467: svc:/application/management/seaport:default: null method su cceeds Jun 9 20:28:41/10: Graph noting svc:/application/management/seaport:default onl ine -> disabled. Jun 9 20:28:41/10: Propagating stop of svc:/application/management/seaport:defa ult. Jun 9 20:28:43/414: stop method for svc:/system/webconsole:console exited with status 0. Jun 9 20:28:43/414: Removing transient contract 129 for svc:/system/webconsole: console. Jun 9 20:28:43/414: Removing primary contract 93 for svc:/system/webconsole:con sole. Jun 9 20:28:43/6: Received event 1 for unknown contract id 93 Jun 9 20:28:43/10: Graph noting svc:/system/webconsole:console online -> disabl ed. Jun 9 20:28:43/10: Propagating stop of svc:/system/webconsole:console. Thanks and regards, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20080609/8cfe90d1/attachment.html>