Doh! Is there any way to "verify" whether I got away with it unscathed or not?

I'm running Device Pkg update again. I get prompted for a single new pkg being available.

Here'st the Event Log of the previous Device Pkg update:

Number of Packages Selected for Install : 57

For Product(s) : CiscoWorks Common Services,LMS Portal,CiscoWorks Assistant,CiscoView,Resource Manager Essentials,Campus Manager,Internetwork Performance Monitor

Install Invoked by user : admin

The Package(s) Selected for Install :

DeviceData, Mdf, Cat2350, Cat2960, Cat2975, Cat3560, miniRMON, PoE, CVCrossLaunch, Cat6000IOS, CVGenericPackage, CBS31x0, MWR, Rtr10000, Rtr3900, Rtr2900, Rtr1900, Rtr1800, NGMARShare, Rtr3800, Rtr7000, Rtr800, Routershare, SwitchAddlets, Cat2960, Cat3560, Cat3750, Cat4000IOS, CatGL3, IAD2400, LibCommon, LibDcma, LibInventory, LibNetconfig, LibSwim, Rtr3200, RtrUBR, SharedDcmaIOS, SharedDcmaSS, SharedInventoryCatIOS, SharedInventoryMDS, SharedInventoryRouter, SharedNetconfigIOS, SharedNetconfigSS, SharedNetshowIOS, SharedNetshowSS, SharedSwim2900XL, Rtr3900, Rtr1900, Rtr2900, Rtr800, SharedSwimIOS, CE500, ASR, Nexus, SharedSwimMDS9000, CMDeviceUpdates

Successfully installed packages (2):

DeviceData(1.6) ,Mdf(1.36)

Installation Completed for : CiscoWorks Common Services

No package(s) to install for : LMS Portal

No package(s) to install for : CiscoWorks Assistant

WARNING :  Cat3750(8.0):Version 8.0 already installed

WARNING :  CE500(5.0):Version 5.0 already installed

WARNING :  IAD2400(7.0):Version 7.0 already installed

WARNING :  Cat4000IOS(16.0):Version 16.0 already installed

Successfully installed packages (21):

SwitchAddlets(1.26) ,Rtr3800(9.0) ,Rtr10000(10.2) ,NGMARShare(1.11) ,CVCrossLaunch(2.2) ,Rtr7000(22.0) ,Cat2960(6.0) ,Rtr1900(1.0) ,MWR(1.0) ,miniRMON(3.3) ,PoE(1.3) ,CVGenericPackage(1.3) ,Rtr2900(2.0) ,Cat2975(1.0) ,Cat2350(1.0) ,Rtr3900(1.1) ,Rtr800(14.0) ,CBS31x0(3.0) ,Routershare(1.2) ,Cat6000IOS(30.2) ,Rtr1800(8.0)

Installation Completed for : CiscoView

Successfully installed packages (32):

SharedInventoryRouter(2.5.2) ,SharedSwim2900XL(2.2.2) ,Cat3750(6.2) ,LibCommon(2.4.2) ,RtrUBR(1.3) ,SharedInventoryMDS(1.5.1) ,CE500(6.1) ,SharedInventoryCatIOS(2.3.2) ,SharedSwimMDS9000(1.6.2) ,SharedNetshowIOS(2.2.3) ,Cat3560(7.3) ,LibNetconfig(2.2.2) ,Cat2960(6.3) ,SharedDcmaIOS(2.4.3) ,Rtr1900(2.2) ,SharedNetconfigSS(1.2.1) ,ASR(2.1) ,SharedDcmaSS(2.2.1) ,IAD2400(1.3) ,Cat4000IOS(7.2) ,LibInventory(3.1.4) ,LibSwim(2.5.3) ,Rtr2900(1.1) ,SharedNetconfigIOS(2.3.2) ,CatGL3(5.2) ,Rtr3900(1.0) ,Rtr800(6.3) ,SharedNetshowSS(1.1.1) ,SharedSwimIOS(2.5.3) ,LibDcma(2.3.2) ,Rtr3200(5.1) ,Nexus(2.3)

Installation Completed for : Resource Manager Essentials

Successfully installed packages (1):

CMDeviceUpdates(6.0)

Installation Completed for : Campus Manager

No package(s) to install for : Internetwork Performance Monitor

Does it mean no harm done to the Device Pkg map?

This means the package map is okay.  Corruption there usually brings up 500 server errors.  As for validating the RME package repository, you should have 330 packages on an up-to-date 4.3.1 server.

That's great news: I do have 330 RME pkgs, and 746 RME device types to match.

So I let it come back autonomously this time. Should I be concerned about some of the downed or failed processes according to the current proc status?

Did you run the installation again?  If so, and if PSU is still performing the installation and daemon restart, then no.  Else, you do have some problems.  There appears to be some issues with the cmf database as well as other processes.  If these processes don't come back up automatically in about 30 minutes, then you definitely have a problem.

I simply let Device Pkg Update install the CiscoView Cat3560 pkg pictured earlier. It's then left unattended. The reason I developed the inclination to manually intervene at all was because I had a similar issue with LMS procs (*OGS* ones) not coming back properly in LMS 3.1 on my production box (alluded to in this thread: https://supportforums.cisco.com/message/2006396#2006396), while LMS 3.2 is currently only on my test box.

Here's the proc status around 5pm yesterday:

Here's the status overnight this morning:

I also want to note that after my manual dmgtd restart, and prior to the installation of the single CiscoView Cat3560 pkg mentioned above, the only processes that didn't come back were:

CWAPublisher Administrator has shut down this server 0 0 0 01/04/10 1#:##:## 01/04/10 1#:##:##

DCRDevicePoll Administrator has shut down this server 0 0 0 N/A Not applicable

After dmgtd stop, I still have these procs up. Should I go ahead with starting dmgtd, or is there something awry here?

casuser 23883     1   0   Dec 23 ?           0:11 /opt/vgi/csco/CSCOpx/objects/wfengine/program/PolicyScheduler
casuser 23878     1   0   Dec 23 ?           0:06 /opt/vgi/csco/CSCOpx/objects/wfengine/program/DataStore
casuser 23880     1   0   Dec 23 ?           0:13 /opt/vgi/csco/CSCOpx/objects/wfengine/program/GGLogger
casuser 23881     1   0   Dec 23 ?           0:05 /opt/vgi/csco/CSCOpx/objects/wfengine/program/GGProxy
casuser 23889     1   0   Dec 23 ?           0:04 /opt/vgi/csco/CSCOpx/objects/wfengine/program/GGHelper
casuser 23879     1   0   Dec 23 ?           0:07 /opt/vgi/csco/CSCOpx/objects/wfengine/program/GGScript
casuser 23882     1   0   Dec 23 ?           1:31 /opt/vgi/csco/CSCOpx/objects/wfengine/program/OpsBREngine

No, these need to be stopped manually before dmgtd can be properly restarted.  Send them a SIGTERM, and if that doesn't work, move to a SIGKILL.

Those procs were killed with SIGTERM just fine. Here's the current proc status. Everything seems to have come up fine. Overall, this seems to mirror what I've seen with LMS 3.1 Device Pkg Update regarding its inability to restart everything properly though.

I have never seen such a problem on Solaris with LMS 3.1 or 3.2.  Device package upgrades always restore a working system.  If you can reliably reproduce, it may be helpful to open a TAC case on your next package update so one can look at the processes as they come back up.