Re: SMF handling for removed packages

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2015-01-13 at 21:42 GMT, Paul B. Henson wrote:

> While pkgsrc automatically installs an SMF service for packages which
> include a manifest when the package is installed, it doesn't seem to have
> any handling for SMF when a package is removed.
> 
> The service is online and running:
> # svcs -a | grep tenshi
> online         20:05:50 svc:/pkgsrc/tenshi:default
> 
> The package is removed:
> 
> # pkg_delete tenshi
> 
> The service remains online and running:
> 
> # svcs -a | grep tenshi
> online         20:05:50 svc:/pkgsrc/tenshi:default
> 
> However, given the files are gone, the next time the service is restarted or
> the machine boots the service will drop to maintenance mode.
> 
> It seems that when an smf supported package is removed, the service should
> be stopped, and removed from SMF?

The problem is that this will break upgrades, as there is currently no
way in pkgsrc to distinguish between an upgrade and a de-install &&
re-install cycle, as they are the same thing.

For example, say a user has modified some SMF attributes:

  $ svcs postfix
  STATE          STIME    FMRI
  online         11:04:30 svc:/pkgsrc/postfix:default

  $ svccfg -s postfix listprop refresh/timeout_seconds
  refresh/timeout_seconds  count    60

  $ svccfg -s postfix setprop refresh/timeout_seconds = count: 30

  $ svccfg -s postfix listprop refresh/timeout_seconds
  refresh/timeout_seconds  count    30

Then emulate the requested behaviour.

  $ svcadm disable postfix
  $ svccfg delete postfix
  $ pkg_add -U postfix

The refresh/timeout_seconds property has now reverted to its default
value:

  $ svccfg -s postfix listprop refresh/timeout_seconds
  refresh/timeout_seconds  count    60

pkgsrc needs good upgrade infrastructure, and this is one of the areas
that will need to be handled properly, but until we have that then I'd
rather not automatically remove SMF manifests.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com