Tom Whitten wrote: > Enda O'Connor ( Sun Micro Systems Ireland) writes: >> Hi >> I am looking at a patchadd failure and the problem is that >> the patch is running a script that runs >> svccfg import console-login.xml ( full path to xml deleted here for >> brevity ) >> and this fails with >> >> svccfg: Conflict upgrading svc:/system/console-login (property >> "ttymon/terminal_type" has different values). > > Did the import fail, or did it succeed and just issue this warning? > >> problem being that I have changed >> "ttymon/terminal_type" to xterm from sun. >> >> Is there any way around this without resorting to having a customer >> manually massaging things. >> This is generic as patches import manifests depending on the patch, >> mainly Kernel patches though, and it appears that any custom >> configuration will lead to this situation. >> >> Plus any upgrade ( LU/jumpstart etc ) will almost certainly lead to the >> same scenario. >> >> Any way to get svccfg to import the config and keep any customisations >> as well. >> >> Enda >> _______________________________________________ >> smf-discuss mailing list >> smf-discuss at opensolaris.org > > If an administrator has changed a property value and the new manifest has > changed the same property in a different way, the import will not override > the administrator's changes. In this case it issues the warning message > that you see above. The import still succeeds, but the property that has > been changed by the administrator does not get changed. > > Here is an example. I created a manifest for a service called bogus_1 with > 4 properties. Here are the properties and my plans for them in this > experiment. > > ttymon/cmd_change - Will be changed using the svccfg > command. > ttymon/man_change - Will be changed in the manifest > ttymon/no_change - Will not be changed at all. > ttymon/terminal_type - Will be changed with svccfg and in manifest > > When I import the original manifest, here are the initial values for > these properties as shown by svcprop. > > ttymon/cmd_change astring original > ttymon/man_change astring abc > ttymon/no_change astring forever > ttymon/terminal_type astring krang > > I then used svccfg to change the cmd_change and terminal_type properties: > $ sudo svccfg > svc:> select bogus_1 > svc:/system/bogus_1> setprop ttymon/cmd_change = changed > svc:/system/bogus_1> setprop ttymon/terminal_type = crung > svc:/system/bogus_1> quit > $ sudo svcadm refresh bogus_1 > > Here are the current property values: > ttymon/man_change astring abc > ttymon/no_change astring forever > ttymon/cmd_change astring changed > ttymon/terminal_type astring crung > > Next I edit the manifest changing the property values for man_change and > terminal_type: > man_change 'abc' -> 'dev' > terminal_type 'krang' -> 'vt100' > > Next I reimported the manifest using the -v option of svccfg to get verbose > output: > $ sudo svccfg -v import bogus_1.xml ; echo $? > svccfg: Taking "previous" snapshot for svc:/system/bogus_1:default. > svccfg: Upgrading properties of svc:/system/bogus_1 according to instance > "default". > svccfg: svc:/system/bogus_1: Upgrading property "ttymon/man_change". > svccfg: Conflict upgrading svc:/system/bogus_1 (property > "ttymon/terminal_type" has different values). > svccfg: Taking "last-import" snapshot for svc:/system/bogus_1:default. > svccfg: Refreshed svc:/system/bogus_1:default. > svccfg: Successful import. > 0 > > Notice that I did get the same conflict warning that you did. The import > did succeed, howerver, and exited with 0. As we will see the import did > not override the administrator's customizations. That is the reason for > the warning. We will also see the man_change property did get changed by > the import shince there was no conflict. Here are the values after the > import: > ttymon/no_change astring forever > ttymon/cmd_change astring changed > ttymon/terminal_type astring crung > ttymon/man_change astring def > > tom > > Hi Sorry not replying earlier, but yes you are right, the import appears to have succeeded, thanks for the info
Enda
