Thank you Mark, You suggested to rename the existing run-once SMF and not to administratively deleted it. But during next pkg update, again run-once do not get executed. I tried with using restart_fmri and disable_fmri actuators together also.
My requirement is to make it call enable action every time a package is updated irrespective of whether SMF is modified or not. Thank you for your time. Thanks & Regards, Sajith -----Original Message----- From: Mark J. Nelson [mailto:[email protected]] Sent: Wednesday, May 02, 2012 10:55 PM To: Sajith C.R. Cc: [email protected] Subject: Re: [pkg-discuss] SMF services not called during pkg update On 05/02/12 07:20, Sajith C.R. wrote: > Hi Mark, >>> When you say "the scripts for enabling/disabling services are not getting >>> invoked," do you mean the run-once SMF service? > >>> If so, this is because it has deleted itself. Service deletion is an >>> administrative customization that is preserved across upgrade. > >>> When pkg restarts the manifest-import service, it will correctly detect any >>> changes in the xml manifests under var/svc/manifest, and will update the >> >>> repository accordingly. It will NOT remove any administrative >>> customizations (enable, disable, delete, change property values) that have >>> been made to >> those services. > > [Sajith] It is about run-once SMF. The SMF service was to port postinstall > functionality and at the end of enable action, deletion of service was done > to ensure that it is performed only once. > > If I want to run/import the run-once SMF again after pkg update, what is the > way? The right solution is for the upgrade service to remain enabled, and to check on startup for conditions that indicate whether or not an upgrade is necessary. For example, have the manifest deliver a property set to the current version of the software, and have the upgrade service compare a "last upgraded version" property to that property. Per smf_method(5), you can use smf_method_exit $SMF_EXIT_TEMP_DISABLE if you detect that no work is necessary. In the mean time, you're kind of in a bind with the existing upgrade service, because you must either remove support for it altogether, or use "svccfg -s your_upgrade_service_fmri delcust" from a different SMF service to unmask it. If you're not keeping track of anything in its properties, I would consider renaming the service, so that the old one really, truly goes away (instead of remaining MASKED), and the new one is never administratively deleted. --Mark > -----Original Message----- > From: Mark J. Nelson [mailto:[email protected]] > Sent: Tuesday, May 01, 2012 11:23 PM > To: Sajith C.R. > Cc: [email protected] > Subject: Re: [pkg-discuss] SMF services not called during pkg update > > On 05/01/12 10:23, Sajith C.R. wrote: >> Hi IPS team, > >> I have a package in p5p format whose manifest contains some SMF >> service for service management and few other as run-once SMF for >> control script purpose. The run-once SMF delete itself once run. > >> The package works fine with pkg install command during fresh install. >> But, it is seen that when same IPS package is used to update an old >> version (which also contains the same SMF services) with pkg update >> command, SMF services are not getting updated or created. The scripts >> for enabling/disabling services are not getting invoked. The SMF >> manifest files are packaged at /var/svc/manifest/system and tagged >> with actuator restart_fmri. >> >> Any idea why pkg update is failing to update / create SMF services? > > When you say "the scripts for enabling/disabling services are not getting > invoked," do you mean the run-once SMF service? > > If so, this is because it has deleted itself. Service deletion is an > administrative customization that is preserved across upgrade. > > When pkg restarts the manifest-import service, it will correctly detect any > changes in the xml manifests under var/svc/manifest, and will update the > repository accordingly. It will NOT remove any administrative customizations > (enable, disable, delete, change property values) that have been made to > those services. > > --Mark > >> Snippet of manifest: >> >> file /pkg/solaris/my-run-once.xml >> path=var/svc/manifest/system/my-run-once.xml owner=root group=sys >> mode=0744 restart_fmri=svc:/system/manifest-import:default >> file /pkg/solaris/my.xml path=var/svc/manifest/system/my.xml >> owner=root group=sys mode=0744 >> restart_fmri=svc:/system/manifest-import:default >> variant.opensolaris.zone=global >> >> Log of manifest-import is not showing any specific errors. >> >> Thanks & Regards, >> Sajith >> >> _______________________________________________ >> pkg-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
