When a manifest is listed in a patch, it must be associated with
its class action scripts. Upon install, i.manifest does import
the new manifest (if the install is local). What the import does
is:
For existing services and instances, properties which
have not changed since the last import snapshot was
taken are upgraded to those specified by the manifest.
Conflicts (properties which have been changed both in
the repository and the manifest) are reported on the
standard error stream.
If a service is online and you add/remove a dependency via a patch
then you have to restart the service for the new dependency to
be checked. If the service was disabled before patching then the
new dep will be verified once the service is enabled.
If by any chance the dep that you're adding is not necessarily
online after patching and it is a require_all dependency then
you should either mark the patch reboot_after or create some
pre/post install script to restart the service if it was online.
(the same applies for exclude_all deps that could be online
while patching).
If you're adding a dep on name-services then you shouldn't have
to do anything - name-services should always be online unless
there is something going wrong on the system.
-- Renaud
Brian Utterback wrote:
> I am trying to find out how Sun patches patch manifests. When a
> manifest is listed in the patch, is the new manifest imported, with
> the changes taking effect immediately, or do they have some kind of
> delayed installation?
>
> In this particular case, the patch is adding a dependency to a
> service. I am trying to decide whether or not to add the "reboot
> required" attribute to the patch. I don't think it should be added,
> but there are some corner cases I am worried about.
>
> We specify "reboot required" when a patch does not make the system
> unstable, but the patch will not take affect until the reboot happens.
> Obviously, we make these distinctions to help customers decide
> whether they reboot sooner or later or not at all. So, if your
> application has failures because of a bug in a kernel driver, and the
> patch installs a new driver, we want you to be aware that you don't
> have to reboot right away, but you also don't get the fix until you do.
>
> So, the thing is, adding a dependency changes the order a service is
> started in on a reboot. So, if we have added a dependency and then do
> not reboot, can the system be said to have the fix or not? There is no
> point in rebooting if the end result is a system in exactly the same
> state as it is now. That presumes that the service is already up and
> running.
>
> If the service is not already up and running, will the new dependency
> be in affect when the service is enabled, after the patch is
> installed. If so, I don't think there is any question, since at that
> point the fix is totally working. If not, then that might be an issue,
> although the new dependency is on the naming service, so the only
> systems on which it would not be enabled is a system that is up and
> running with the naming service turned off. That doesn't sound too
> typical.
