Quoth David Powell on Mon, Oct 16, 2006 at 04:36:28PM -0700: > On Mon, Oct 16, 2006 at 04:11:27PM -0700, John Beck wrote: ... > > Fortunately, an SMF expert happened to walk by just at this time, and told > > us that we needed to refresh the service even after rebooting; once we did > > so, `svcprop` started reporting the desired value, and a subsequent restart > > of the service resulted in mail flowing. > > > > So my question is: why didn't the reboot constitute an automatic refresh > > as we thought it would? The current behavior seems counter-intuitive. > > A refresh to commit changes is needed on reboot for the same reason a > refresh is needed when restarting a service. > > Without a refresh, a service which restarts (e.g. because it > encountered an error) could read a configuration which is in an > inconsistent intermediate state. The refresh takes the edited > version of the configuration and makes it active all at once, so you > either get the old configuration or the new -- not something in > between. > > The same principle applies on reboot. The system could reboot when > the configuration is in an inconsistent state. Only when the > administrator says so will SMF consider the edited version of the > configuration consistent and usable.
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? 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? Clearly refresh isn't an intuitive consequence of the model which svccfg presents, and our silence doesn't help. > 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. 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? David
