On Mon, 7 Jul 2008, Kyle McDonald wrote:
> James Carlson wrote:
>> Kyle McDonald writes:
>>
>>> James Carlson wrote:
>>>
>>>> Did you perhaps forget the 'refresh'? If so, I'll close out this bug.
>>>>
>>>>
>>>>
>>> Nope. I rebooted. Doesn't 'reboot' imply a 'refresh' ;) ??
>>>
>>
>> No, it does not. You must explicitly do "svcadm refresh" if you want
>> the altered parameters (set in the service) to apply to the existing
>> service _instance_.
>>
>> As I was suggesting, please try a "refresh", and if that works, I'll
>> close out the bug.
>>
>> (Perhaps there's a separate complaint here about SMF's design and the
>> need for "refresh", but that looks out of scope for the bug filed.)
>>
> Ok so the refresh did work.
>
> Odd, because in earlier builds the Terminal type change took effect on
> reboot, but the label one didn't.
> When I saw both changes missing this time I finally got around to filing
> a bug.
There's a bug somewhere where one of the scf_ functions reads the wrong
value, but I don't think that's the issue here. I'm not sure why it would
have changed.
>
> So as I undertssand it now, there is some 'middle' location where the
> settings are cached, and service startup reads the setting from there,
> and not directly out of SMF? I knew about 'refresh' and thought it was
> great for triggering running processes to reread their config, but as
> rebooting (and 'restart') involve the service starting up from scratch
> it was my understanding that that would include rereading the config.
>
It reads it out of SMF, just there is an in-progress edit, and a committed
state. When you refresh your service you tell it to use the committed
state.
refresh {FMRI | pattern}. . .
For each service instance specified by the operands,
requests that the assigned restarter update the
service's running configuration snapshot with the values
from the current configuration.
-- Dave
