vxconfigd behaves erratically if there is more than 40GB of physical memory on an AIX system

  • Modified Date:
  • Article ID:000010797


vxconfigd behaves erratically if there is more than 40GB of physical memory on an AIX system.    The following are some of the reported erratic behavior.

1. Running "vxdctl enable" causes vxconfigd to lose the licenses

2. Veritas Volume Manager (VxVM) commands fails because of "Memory allocation failure" error

3. vxconfigd dies on the Veritas Volume Replicator (VVR) secondary during synchronization started by "vradmin syncrvg" command

Please note that there can other unpredictable errors reported by vxconfigd.

Error Message

The following are some of the reported errors when the problem is hit:

1. Loss of License

# vxdctl enable
VxVM vxconfigd ERROR V-5-1-1589 enable failed: License has expired or is not available for operation
        transactions are disabled.
VxVM vxdctl ERROR V-5-1-1589 enable failed: License has expired or is not available for operation

#vxdctl license
no features

2. VX commands fail

vxconfigd can cause VX commands to fail with "Memory allocation failure". 

For example, a "vxdg init" command can fail with the following error.

VxVM vxdg ERROR V-5-1-585 Disk group dg_74: cannot create: Memory allocation failure

3. vxconfigd core dumped

vxconfigd can coredump on a VVR secondary while resynchronization (vradmin syncrvg) is running.

#dbx /sbin/vxconfigd.5.3 /core
IOT/Abort trap in pth_signal.pthread_kill [/usr/lib/libpthread.a] at
0xd0124734 ($t1)
0xd0124734 (pthread_kill+0x88) 80410014         lwz   r2,0x14(r1)
(dbx) where
pth_signal.pthread_kill(??, ??) at 0xd0124734
pth_signal._p_raise(??) at 0xd01241a4
raise.raise(??) at 0xd0388cd0
abort() at 0xd03ecb78
__assert_c99(??, ??, ??, ??) at 0xd03f7b8c
ddlproperty.ddl_get_asso_ts() at 0x10076ce4
ddlproperty.ddl_get_dynamic_attr() at 0x10077ddc
ddlproperty.ddl_check_for_dynamic() at 0x10077fc4
ddlproperty.get_asso_ts() at 0x10078b78
req_ddl_get_assoc() at 0x1004a86c
request_loop() at 0x1000c798
main() at 0x10001498



The problem was caused by the Etrack incident listed in the Supplemental Material section of this article.   There was an explicit ulimit() call inside vxconfigd to set the DATALIM (Data Segment Limit).    The Data Segment Limit was set to 10% of the total physical memory by the explicit ulimit() call.    Due to the Etrack incident a 32-bit value is used.   If the system has a physical memory of more than 40960MB (about 40GB), the 10% of this value will overflow the 32-bit variable and as a result incorrect parameter is passed to ulimit().   Depends on the actual physical memory size, this can cause vxconfigd to limit its own Data Segment Size to a very low value.    If the Data Segment Size is too low, vxconfigd will behave erratically.


The problem is fixed in the following patches on the AIX platform.

VxVM 5.1SP1 and onwards

VxVM 5.1RP2 and onwards

VxVM 5.0MP3 RP4  and onwards

Symantec always recommends customers to apply the latest official patches if possible.   Please download the latest patches from the Symantec Operation Readiness Tools (SORT) website.


If applying the above official patches is not possible, a hotfix is available on the 5.0MPRP3 patch level.

VxVM 5.0MP3RP3 HF3

Pleaes contact Symantec technical support if the hotfix is required.

Applies To

This problem is specific to the AIX platform only.

This issue only applies to configuration where all of the following apply:

1. Veritas Volume Manager 5.0MP3RP3 or below, VxVM 5.1 RP1 or below

2. AIX system with more than 40GB of physical memory 

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



Did this article answer your question or resolve your issue?


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


How can we make this article more helpful?

Email Address (Optional)