OpenSolaris

Printable Version Enter a New Search
Bug ID 6470919
Synopsis r.manifest shouldn't insist that the service is permanently disabled
State 10-Fix Delivered (Fix available in build)
Category:Subcategory utility:smf
Keywords rtiq_reviewed | smf | xen
Responsible Engineer Renaud Manus
Reported Against s10 , e_001
Duplicate Of
Introduced In solaris_10
Commit to Fix snv_98
Fixed In snv_98
Release Fixed solaris_nevada(snv_98)
Related Bugs 6518379
Submit Date 14-September-2006
Last Update Date 10-September-2008
Description
Currently, r.manifest does:

                        #
                        # Determine whether any of our instances are
                        # enabled.
                        #
                        en_p=`$SVCPROP -C -p general/enabled $fmri 2>/dev/null`
                        en_o=`$SVCPROP -C -p general_ovr/enabled $fmri 2>/dev/null`

                        if [ "$en_p" = "true" -o "$en_o" = "true" ]; then
                                echo "$fmri remains enabled; aborting"
                                exit 1
                        fi

That is, even if a service is temporarily disabled, r.manifest will still fail.
This seems odd behaviour, and causes problems for Xen: if someone boots into
i86pc, the services will be temporarily disabled but not permanently disabled,
preventing removal of the Xen packages.

David Bustos commented:

I believe that's a bug.  It should probably be using the state anyway.
Actually, failing installation in class action script is incorrect and violates the SVR4 pkg design. One of the obvious consequences for breaking the rules is partially removed package (broken) after such failure.

Further downstream, this also poses problem for patching that is non-interactive by its nature and failing it mid-run can be rather disastrous (partially patched system not possible to move either way without manually editing /var/sad/... pkg'ing db area).
Work Around
N/A
Comments
N/A