5.1 SP1 RP1 executing vxdisk updateudid on a disk which is initially reported as "online udid_mismatch" followed by "online invalid" can result in the vxconfigd daemon core dumping

Problem

When attempting to recover a series of failed devices back into an imported diskgroup, the "vxdisk updateudid" command was executed to clear the harmless "udid_mismatch" flag.

As a result of running the "vxdisk updateudid <da-name>" command, the vxconfigd daemon core dumped.

Error Message


Sample pstack output for vxconfigd core file

# cd /

# file core
core:           ELF 32-bit MSB core file SPARC Version 1, from 'vxconfigd'

# ls -la core
-rw-------   1 root     root     27801826 Nov 19 00:40 core

 


# pstack core
core 'core' of 59:      vxconfigd -x syslog -m boot
-----------------  lwp# 1 / thread# 1  --------------------
 00116364 priv_join (8427b8, 6e9150, 6, 2, 36f000, 6daa08) + c
 0009efb0 req_disk_updateudid (0, 1, 0, 6e9150, 6c2e58, 6e9148) + 230
 00133ef4 request_loop (0, 379f88, 811b20, a8c0, ffffffff, 1537e) + b38
 000ffac4 main     (36d800, 3cf400, 38d400, 2ec000, ffbffe3c, 0) + fd0
 00041cf0 _start   (0, 0, 0, 0, 0, 0) + 108
-----------------  lwp# 139 / thread# 139  --------------------
 ff1c9594 __lwp_park (0, 3cad38, 0, 0, 6d0dc, 0) + 14
 ff1c35d8 cond_wait_queue (3cad28, 3cad38, 0, 0, 1c00, 0) + 4c
 ff1c3b20 cond_wait (3cad28, 3cad38, 0, 1c00, 0, 3cad38) + 10
 ff1c3b5c pthread_cond_wait (3cad28, 3cad38, 0, 0, 3cad38, ff1c2a78) + 8
 00134acc vold_dispatch_requests (2, 379c00, 3cad38, 377e80, 3cac00, 3cac00) + 7c
 ff1c94f0 _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 140 / thread# 140  --------------------
 ff1ccd90 _pause   (




 

Cause

Product Defect Etrack 2189812

Solution



Workaround



Following the vxconfigd death state, the daemon can be restarted by typing:

# vxconfigd

To validate that the vxconfigd daemon has been restarted successfully, type:

# vxdctl mode

The command should state that the vxconfigd daemon is in an enabled state:

# vxdctl mode
mode: enabled

Symantec engineering are working on a fix at this time.


Recommendations
 

To increase the chances of diskgroup recovery, it is recommended that the number of configuration copies saved in the /etc/vx/cbr/bk/<disk_group> directory be increased from the default of  "1" (for all VRTSvxvm 5.x releases) to "3" where possible.

The CBR directory can have more than 1 copy by creating the /etc/vx/cbr/bk_config file with "NUM_BK=<value>" for the number of configuration copies to be maintained:


# echo "NUM_BK=3" >> /etc/vx/cbr/bk_config

The above file would increase the number of copy copies to "3" for each diskgroup.

 


Terms of use for this information are found in Legal Notices.

Search

Survey

Did this article answer your question or resolve your issue?

No
Yes

Did this article save you the trouble of contacting technical support?

No
Yes

How can we make this article more helpful?

Email Address (Optional)