>[...]
> Another possible way to maintain consistency would be to make a bare
> "svcadm disable ..." on a service with active dependents fail, and
> require either "-f" (force == pretend as though a failure occurred,
> and do the same as today) or "-r" (recursive == administratively
> disable dependents in reverse order first, and then shut down this
> service) to handle this case.
>
> I'm no fan of the "must dial 1 first" school of interface design, but
> I'm not sure that having failure into offline mode occur in two
> different orders (reverse order if done by administrative action,
> forward order if done by actual service failure) is a good thing.
>
> --
> James Carlson, Solaris Networking
I would consider this a very helpful model, with one possible refinement:
svcadm disable foo
Error: Would offline dependendent services:
fubar
Use "svcadm disable -d ..." to disable service and its dependents,
or "svcadm disable -f ..." to force offline as if it had failed.
We see a similar model when deleting zfs snapshots that have clones, etc.
Disabling services in "forward order" (dependencies before dependents)
is a bug that's already causing problems. For example, autofs with nwam
takes about five minutes to shutdown because the NIC has apparently
lost it's IP address before autofs could finish doing a graceful unmount.
We really need to do (graceful) shutdown in "reverse" order.
I'm surprised this hasn't come up before now.
Gordon
This message posted from opensolaris.org
