Script started on Wed 14 Jun 2006 09:22:09 PM CST # svcs -x ntp svc:/network/ntp:default (Network Time Protocol (NTP)) State: offline since Wed 14 Jun 2006 09:19:33 PM CST Reason: Start method is running. See: http://sun.com/msg/SMF-8000-C4 See: xntpd(1M) See: ntpdate(1M) See: ntpq(1M) See: /var/svc/log/network-ntp:default.log Impact: This service is not running. # ps -ef | grep ntp root 387 7 0 21:19:33 ? 0:00 /sbin/sh /lib/svc/method/xntp root 392 387 0 21:19:33 ? 0:00 /usr/sbin/ntpdate -s server # svcadm disable ntp # svcs -x ntp svc:/network/ntp:default (Network Time Protocol (NTP)) State: offline since Wed 14 Jun 2006 09:19:33 PM CST Reason: Start method is running. See: http://sun.com/msg/SMF-8000-C4 See: xntpd(1M) See: ntpdate(1M) See: ntpq(1M) See: /var/svc/log/network-ntp:default.log Impact: This service is not running. # ps -ef | grep ntp root 387 7 0 21:19:33 ? 0:00 /sbin/sh /lib/svc/method/xntp root 392 387 0 21:19:33 ? 0:00 /usr/sbin/ntpdate -s server # script done on Wed 14 Jun 2006 09:22:40 PM CST
So what do I think is wrong here? 1) "svcadm disable ntp" has no affect on anything 2) "svcs -x ntp" does not make sense. "Start method is running" but it is "offline". This should probably be "i'm disabling myself" 3) there is no output from "svcadm" telling me this Whether or not there were other "issues" with networking is immaterial, unless "svcadm disable" is going to report an error, it should offline the service (including kill the running processes) and update "Reason". This is a good reason why svcadm should return status, because sometimes it just doesn't do what the person interacting with it expects it to do. If this is our interface to control running processes inside services then it should actually provide us that control, not just "set a flag" and return. In a conversation with someone last year, they put it to me that if you were putting this in a script, you would just issue the "disable" and no more problems. This is clear evidence that just doing "svcadm disable" is not nearly reliable enough of an action for that kind of treatment. My experience to date is that when everything is right and working fine, SMF is nice to deal with. But when something isn't working right (especially network services) then it is far far worse than what were expected to do with prior Solaris. Personally, I don't care if the service is still doing its start method or something else. If disable (and -t) are the only proper hooks to stop a service then that is what I expect it to do, not futz around and pretend. Darren
