[OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

Lauri Tirkkonen lotheac at iki.fi
Fri Oct 23 06:32:03 UTC 2015


We may be getting a bit off topic here :)

On Fri, Oct 23 2015 01:13:59 +0200, Volker A. Brandt wrote:
> Lauri Tirkkonen writes:
> > Well, that's not a design flaw. Actuators are executed only when the
> > action (eg. file) specifying them changes
> 
> Yes, this is how IPS does it.  IPS does not really know that the
> manifest-import service is special.  There should have been an explicit
> "re-import this manifest now" actuator, much like users or groups are 
> created.

But it isn't really that special. If you ship a different service
manifest, it gets reimported with 'svccfg import' -- but this does *not*
affect whether the service is running or restart it (IME). Reimporting a
manifest does, however, cause a service refresh, but the refresh action
doesn't necessarily restart any processes:

    mail ~ # svcs spamd
    STATE          STIME    FMRI
    online         Sep_30   svc:/mail/spamassassin/spamd:default
    mail ~ # svccfg import /lib/svc/manifest/mail/spamassassin-spamd.xml 
    mail ~ # svcs -vp spamd
    STATE          NSTATE        STIME    CTID   FMRI
    online         -              6:15:41    341 svc:/mail/spamassassin/spamd:default
                   Sep_30       3619 spamd
                   Oct_20      19590 spamd
                   Oct_16      29484 spamd
    mail ~ # tail -2 $(svcs -L spamd)
    [ Oct 23 06:15:41 Rereading configuration. ]
    [ Oct 23 06:15:41 No 'refresh' method defined.  Treating as :true. ]

I don't know what you mean with the bit about users and groups; AFAICT
the logic is similar to other actions.

> [...]
> > If you wanted to restart ntp when any files in the ntp package
> > change on update, you would need an actuator like
> > 'restart_fmri=svc:/network/ntp:default' on *all* file actions
> > delivered by the package.
> 
> I know what you mean.  That might work, but that is normally not what 
> you do when you deliver an SMF manifest in your package.  You just drop
> it and restart manifest-import, and hope that manifest-import will see
> your new manifest.  This is quite a different thing.

It is actually what I normally do, because no other way works :) See for
example the following mog file for ISC bind:
https://github.com/niksula/omnios-build-scripts/blob/master/bind/local.mog#L6
Even the manifest-import restart is an actuator added by omnios-build (from
global.mog), nothing happens automatically.

> Also, what you wrote is not quite true.  What you wanted to write was 
> "you would need an actuator on *at least one* file action *that has a
> different file hash*".  If nothing is different, the action is not
> executed, and the attached actuator does not fire. 

We're both correct. Note that I said "when _any_ files in the ntp package
change on update" (emphasis added).

> And it gets worse when you remove a package that contains a manifest for
> a running SMF service, because it is impossible to call the stop method
> of the service before removing the package.  Lots of fun. :-)

I don't know why it would be impossible before or even after removing the
package. After the manifest has been imported into the SMF repository, the
service will not go away even if you remove the xml manifest it came from.

If you meant that pkg can't automatically stop your service when removing a
package, maybe disable_fmri is something you want? From pkg(5):

    disable_fmri causes the given FMRI to be disabled prior to action
    removal, per the disable subcommand to svcadm(1M).

-- 
Lauri Tirkkonen | lotheac @ IRCnet


More information about the OmniOS-discuss mailing list