* Darren Reed <Darren.Reed at sun.com> [2007-09-25 00:58]:
> Stephen Hahn wrote:
> >* Peter Tribble <peter.tribble at gmail.com> [2007-09-15 15:31]:
> >>On 9/13/07, Liane Praza <lianep at eng.sun.com> wrote:
> >>...
> >>
> >>>>What I need is the ability to install a service so that it starts out
> >>>>permanently enabled but currently disabled. Without doing
> >>>>an enable followed by a disable -t.
> >>>>
> >>>>
> >>...
> >>
> >>>Thus: would a single command to explicitly leave the service
> >>>in a temporarily disabled/permanently enabled mode solve your
> >>>operational request, or is there more you think needs to be explored?
> >>>
> >>>
> >>I think that's basically it. However, another way of putting it is like
> >>this:
> >>
> >>At present, svcadm enable/disable changes both the current and permanent
> >>state of a service.
> >>
> >>We can change the current state of a service, leaving the permanent state
> >>unchanged with the -t option.
> >>
> >>What we need is the counterpart that changes the permanent state of the
> >>service without affecting the current state. Maybe enable/disable -p?
> >>
> >>My expectation is that this would require the same level of permission
> >>as a regular enable/disable.
> >>
> >>
> >
> > That sounds pretty reasonable as an RFE to me. The various
> > smf_{disable,enable}_instance(3SCF) interfaces currently take
> > SMF_TEMPORARY, with persistent being the default. Movement into
> > maintenance has the addition of SMF_IMMEDIATE. SMF_POSTPONED or
> > SMF_DEFERRED, maybe?
>
> What would the interaction be between the new flag and
> "svcadm refresh"?
As proposed so far, there is no new interaction. (The general/enabled
property value is already understood specially by svc.startd(1M),
without reference to the running snapshot.) But I'm interested in
alternative proposals, of course.
- Stephen
--
sch at sun.com http://blogs.sun.com/sch/
