On 9/15/07, Stephen Hahn <sch at sun.com> 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?
Maybe "svcadm automatic | manual' (No need to reinvent the wheel, at
even turn of the road)
(I so wish it had been: start/stop instead of enable/disable)
>
> - Stephen
>
> --
> sch at sun.com http://blogs.sun.com/sch/
> _______________________________________________
> smf-discuss mailing list
> smf-discuss at opensolaris.org
>
--
- Brian Gupta
http://opensolaris.org/os/project/nycosug/
