Nicolas Williams wrote:
On Thu, Jul 22, 2010 at 09:43:37AM -0400, Mark Haywood wrote:
What is the console message ?
As mentioned in the case:

"Similarly, if the IPMP service is disabled while IPMP groups are
configured, the service stop method will display warning messages to
the console."

This is useless: the user doing the stopping won't be on the console,
and the message will be useless noise at shutdown time (since the
service can't tell if a stop method invocation is for shutdown or some
other purpose; see aside below).

Besides, there are plenty of services that should be running when some
feature is enabled, and which don't output such messages.  For example,
in.iked (if the output of ipsecconf -l shows protect rules then chances
are you need in.iked running, and if you don't it's because you're using
manually-keyed SAs, which is not a good idea).  There are other examples
(NFS? check. idmap? check. etcetera).

Agreed. And after looking at other services and investigating transitioning into maintenance mode when the service is disabled, I believe that the best course of action is simply to get rid of the message. Switching into maintenance mode would require the user to unconfigure all IPMP groups to get back out of maintenance mode. This is not acceptable.

Mark


Even if such a message were desirable, you could still have it be output
by in.mpathd rather than having to create a stop method script.  But
just get rid of this message.

[It might be nice if SMF could distinguish between kinds of service
stops.  Some services might care whether they are being stopped by a
sysadmin, stopped as part of restarting, or stopped as part of shutting
down the system.  In the first case a service might well refuse to stop
and have its stop method return an error, because not running when the
service is absolutely necessary could result in a broken system.  But
that's not this case, and in.mpathd does not seem like case where
preventing manual service stops is crucial.  Though an RFE against SMF
for this is probably a good idea.]

Nico

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org

Reply via email to