On Mon, Oct 23, 2006 at 02:33:51PM -0700, David Bustos wrote: > Isn't "counter-intuitive" a tip-off that this is primarily a usability > problem? If refresh is required after making modifications in svccfg, > shouldn't svccfg say "Refresh is required to enact your modifications" > on exit?
I think a reminder on exit would be very helpful. > Or shouldn't svccfg grow a refresh/commit command and say "You > haven't committed your changes yet, do you really want to quit?" on > exit? The ability to commit from within svccfg would certainly bring it into greater alignment with similar interfaces, and seems appealing... at least at first. Having two different ways to commit changes (svccfg and svcadm) feels a little odd, though. > Clearly refresh isn't an intuitive consequence of the model which > svccfg presents, and our silence doesn't help. Though the svccfg command behaves in accordance with a particular model, I don't think one's interaction with it is rich enough to say that svccfg "presents" a model. I'd agree that refresh isn't an intuitive consequence of years of experience with a non-SMF model. > > The part of the above scenario that seems wrong to me is not the need > > to refresh, but the need to restart. A 'svcadm refresh' is supposed > > to tell SMF to (roughly): > > a) Make the edited configuration the active configuration, and > > b) Instruct the service to re-read its (new) configuration. > > > > If a restart is needed to make changing the local_only property > > register with sendmail, it sounds like there's a problem with > > sendmail's refresh method. > > True, but there's a lot of software which only reads configuration on > startup and requiring them to change configuration dynamically usually > (always?) requires a rewrite, so we should accommodate such software. So they shouldn't pretend to be refreshable, and we restart them when a refresh is needed. > Especially since there are some properties which can't be refreshed due > to Solaris, like the process context properties. And the inetd > properties that Stafford was dealing with (can't remember which now). > > Perhaps the service should have a property which flags it as > "refresh-isn't-enough", and svcadm refresh can print a message about > this? 'svcadm refresh' should always be enough. The only exception I'd make is if you want to call out a class of settings for which it never will be -- e.g. process context changes. I'd prefer to have an arrangement which encourages developers to better integrate with SMF (i.e. forcibly restarting non-refreshable services) than one which requires every SMF consumer to code around the possibility of a non-refreshable service. The latter requires more work (from a global perspective), is error prone (some people may not handle the case or may do so incorrectly), and entrenches support for a semantic that I hope would become more obsolete over time. Dave
