Alan Maguire wrote:
> Peter Memishian wrote:
>> > I went through the suggested fix in the bug report, and generally
>> that > was the approach I had been considering as well. In addition
>> to making > this private (we can quibble about naming later), I'd
>> also do an > explicit check to see if we're operating without
>> SVCCFG_REPOSITORY set, > and fail plus issue a message saying that
>> svcadm refresh is the droid > you're looking for.
>> >
> thanks for the feedback Liane! i've made changes along
> those lines, let me know if they're what you had in mind
>
> http://cr.opensolaris.org/~amaguire/svccfg_refresh/
I'll look at it this afternoon.
> in terms of other things to be done i suspect we'd like to add a
> few test cases to the SMF test suite to cover this option too?
> and i guess we'll need to settle on a name. if "refresh" is too
> loaded, what about "rotatesnap"/"refreshsnap", or something
> along those lines that is more explicit about the fact that we're
> messing with snapshots (and not additionally running methods,
> as the "real" refresh does)?
After some consideration, here's my suggestion.
Let's just make it "refresh" and make it public. For convenience, in
the non-SVCCFG_REPOSITORY case, it'll call svcadm refresh. Otherwise,
it'll use your original code. The detection you wrote for failure will
now be used for good instead of evil. ;)
The reasons for making it public:
- it won't be harmful if people have called it even once we have early
manifest import,
- potentially i.manifest/r.manifest might be improved using it, and
- most importantly, it allows the "boot net/cdrom" repair scenario
to do service refreshes.
Here's a first rough sketch of a case. Alan, let's work together on
this and see if we can't get it submitted later today.
svccfg refresh subcommand
1. Introduction
Introduce a "refresh" subcommand to svccfg to allow updates to the
"running" snapshot of an instance when the service's restarter isn't
available.
2. Technical Description
SMF's restarters operate on the "running" snapshot of service
instances. This "running" snapshot is taken at two points:
- by svc.startd when the service is started and no
running snapshot is yet available, and
- by svc.startd in response to a "svcadm refresh" request.
Currently, svccfg has an environment variable and a "repository"
subcommand to allow configuration manipulation on an alternate
repository. All manipulation is possible using svccfg except for
the final commit of current configuration changes into the running
snapshot.
This is an oversight, because offline manipulation of the repository
does not allow a manual commit. We propose to introduce a new
"refresh" subcommand to svccfg(1M). If svccfg is operating on
the repository for the live system, this subcommand will
invoke svcadm refresh to accomplish the standard refresh actions
(rotate the snapshot and invoke the refresh method). If svccfg
is operating on an alternate repository, only the snapshot will
be rotated.
3. Interface Table
Interface Stability Binding
--------- --------- -------
refresh subcommand for svccfg(1M) Committed Patch
4. References
5. manpage diffs
liane
