Friday Feb 03, 2012

Changes to svccfg import and delete

The behavior of svccfg import and svccfg delete fmri has changed in S11 if the manifests are in SMF's standard locations. The standard locations are /lib/svc/manifest and /var/svc/manifest with /lib/svc/manifest being the preferred location. If your manifest is stored under one of these two directories, you shouldn't be using svccfg import at all. You should only use svccfg delete fmri when you are prohibited from removing the manifest for some reason and still want to remove the service from the system. Instead, the preferred action is:

        # svcadm restart manifest-import


The reason is that in S11, SMF keeps the repository in sync with the files in the standard locations, and the manifest-import service is the mechanism for maintaining this synchronization. So instead of using svccfg import copy your manifest to a standard location and type:

        # svcadm restart manifest-import
Instead of using svccfg delete remove your manifest from its location and restart manifest-import.


In each case manifest-import will detect any changes in the standard directories and update the repository accordingly. Note that the manifest-import service runs asynchronously from the svcadm command, so it may take a short amount of time for the changes to take effect.

Also the manifest-import service not only detects file additions and removals. It also detects changes to manifests and profiles. If you are a service provider, this gives you an upgrade path if your manifest changes. Simply deposit your new manifest over the old one and make sure that manifest-import is restarted. Restarting of manifest-import is usually handled by the packaging service.

Let's look at some examples. First, let's get the manifest for our new service imported.

# cp mysvc.xml /lib/svc/manifest/site
# svcadm restart manifest-import
# svcs mysvc
STATE          STIME    FMRI
online         15:19:41 svc:/mysvc:default
Now delete the service:
# rm /lib/svc/manifest/site/mysvc.xml 
# svcadm restart manifest-import
# svcs mysvc
svcs: Pattern 'mysvc' doesn't match any instances
STATE          STIME    FMRI


Now let's look at what happens if you stray from this advice and use svccfg delete. First, reinstall the manifest just as we did before.

# cp mysvc.xml /lib/svc/manifest/site
# svcadm restart manifest-import
# svcs mysvc
STATE          STIME    FMRI
online         15:34:41 svc:/mysvc:default
Now the fun begins.
# svccfg delete -f svc:/mysvc
# svcs mysvc
svcs: Pattern 'mysvc' doesn't match any instances
STATE          STIME    FMRI
It looks as if the service has been removed from the repository, but it really hasn't been. Since the manifest file is still on the file system, the service is merely masked in the repository. This can lead to confusion. Even if you modify the manifest and restart manifest-import, svcs will not find the service. This is because the masking is done at the administrative layer (see Sean Wilcox's discussion of layers). The masking is not removed by changing the manifest, although manifest-import will record the changes in the repository.


How can we find a masked service.

# svccfg listcust -M | grep svc:/mysvc
svc:/mysvc manifest MASKED
svc:/mysvc:default manifest MASKED
The first line of output shows that the service is masked. Masking a service also masks it instances which is why we see the second line.


So if you accidentally mask a service, how can you unmask it? We enter svccfg interactive mode, select the service and then use the delcust command.

# svccfg
svc:> select mysvc
svc:/mysvc> delcust
 Deleting customizations for service: mysvc
svc:/mysvc> quit
# svcs mysvc
STATE          STIME    FMRI
online         15:50:46 svc:/mysvc:default
The svcs command shows that the service is unmasked.


Standard Locations (why?)

The manifest-import service manages importing of manifests that are delivered as part of a package for an application.  This instantiates the service and its instances on the system.  The manifest-import service will then manage re-importing those manifests if they are modified/upgraded in some way.

Also, the manifest-import service manages the application of profiles that are in the standard location for profiles of /etc/svc/profile/site.  If these profiles change or are removed then the support for them can be removed from the services on the system.

Finally once the application has served its purpose and the delivering package is removed from the system along with the removal of the manifest the service will then be cleaned up by the manifest-import service.

With that the manifest-import service needs a well known place to be able to find the manifests for a service, and be able to find those manifests under a certain set of rules.  One, the cleanup side of the service needs to be able to know for sure that a manifest is removed and not that a location is simply temporarily unavailable.

Before the Solaris 11, the manifests were located in /var/svc/manifest.  But this location might or might not be available at boot because /var can be a separate filesystem, that is not mounted early in boot.  With the Solaris 11, the manifests were moved to /lib/svc/manifest so that the manifests would be available at the beginning of system boot. Therefore, manifests are to no longer be placed in /var/svc/manifest as it is strictly supported for backwards compatibility only.

So with this standard location that is guaranteed to be available at boot SMF can now make sure that changes and upgrades to manifests are imported before any services are started.  This way services that need to start early in the boot cycle (even before /var might be mounted, if the manifest is in /lib/svc/manifest) will be guaranteed to start with their new property values.

Also, if the manifest is removed from the system, there is a chance for the service to be removed from the system before it attempts to start and does not find the service binaries and/or other files that may be required for the service to run.

Put your manifests and profiles in the standard location and let SMF manage your import, apply and ultimately the cleanup of your services and instances.

So in summary the benefits are :

1. manifests can be imported early in boot before any services are started that might use the information from the manifests.
2. upgrades of manifests and profiles can be done during this early boot phase as well, so that services get the new information before they start.
3. if manifests are removed, then the manifest-import service that manages these can know for sure that the manifests are removed and clean up the services.
4. manifests in a standard location are the base layer for services and their property group and property sets.

Wednesday Nov 09, 2011

Introducing SMF Layers

SMF Layers, meta data for your services.  With S11 we added a new feature that will allow for better tracking of where services, instances, property groups and properties originate and how they may change over there life span. We store a layer at which the entity exists.  At this time there are 4 layers at which an entity can exist.  These layers are based on the location of its delivering or contributing data.

The layers are :

system profile
site profile

Manifest layer entities are delivered or contributed from a standard location for manifests, /lib/svc/manifest or /var/svc/manifest.

System profile layer entities are delivered in the system profile.  A profile that is delivered by Solaris as part of the operating system itself.  At this time this is the generic.xml manifest and a select few other files included into that file.

Site profile layer entities are delivered in a profile located under the /etc/svc/profile/site directory or a subdirectory created under this directory.

Everything else falls under the administrative layer.  Anything delivered outside of the standard locations for manifests and profiles.  As well as any command line creation of entities whether it be through svccfg or the libscf(3LIB) interfaces.

Starting at the manifest layer (the lowest) each of the next layers will override the previous layer.  Although, each layer's data is stored in the repository so that, if one of the higher layers is removed, it will reveal any underlying layers.  This makes upgrading but not overriding higher layer changes a simple action of putting the new files in place and letting the entities be
added to their appropriate layer.

One of the primary concepts we kept to when designing and implementing this project, was that the repository must represent the filesystem in the standard locations, and all other changes are administrative customizations to the system.

So how do Layers benefit us?  Layers allow us to properly upgrade service configurations while preserving customizations.  They provide better observability into service configurations, and the ability to undo customizations

Solaris Service Management Facility information, tips and tricks.


Top Tags
« April 2014