Mario Truyens writes: > Hi, > > I have been working with SMF for more than a year now, and I have to say > that it's causing more problems then it's resolving. > I just want to describe an issue I'm having lately: > Oracle databases and corresponding listeners have been brought under SMF > control via the ora-smf package (not officially supported, but the only > one available). > Now, when a listener dumps core, it's stopped by SMF via the regular > listener stop script (I know you can prevent that, but maybe I don't want > to). This stops only the listener and not its clients. > The real problem is now that any clients of the listener are under the > same contract, and for SMF, the service is forever in the transitional > state online* (moving to offline), until all processes under the same > contract are gone. > This is already a problem,
That does seem like a problem with how the service was written... the stop method should take care of cleaning up everything underneath it. > but now comes the surprise: until all these > processes are killed (by hand), and the listener service has completed its > transition, SMF will not execute any other command (enable, disable) for > any other service! > So any service which is not able to complete a transition will block the > entire SMF. It seems that svc.startd is not really multi-threaded... I tried an experiment to confirm your assertion, because I was surprised -- this case is supposed to work and svc.startd is very multi-threaded. I inserted a sleep into the sendmail stop method, so that it would sleep for 40 seconds and stay in this transitional state, then did this: # svcs zones STATE STIME FMRI online 7:43:22 svc:/system/zones:default # svcadm disable sendmail # svcs sendmail STATE STIME FMRI online* 8:00:07 svc:/network/smtp:sendmail # svcadm disable zones # svcs zones STATE STIME FMRI disabled 8:00:11 svc:/system/zones:default # svcs sendmail STATE STIME FMRI online* 8:00:07 svc:/network/smtp:sendmail Zones was correctly disabled. Perhaps you could describe the exact scenario you're seeing in more detail, including precisely what you're doing, the release you're running, and including the output of: # mdb -p `pgrep startd` > ::startd_log If you try to run enable/disable on the *same* service as is in transition, it will be blocked behind the current action. But, enable/disable on any other service that isn't in the middle of another action should work fine. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
