HP-UX Ignite list_expander error

[BR769215]

Hi. I try to start make_net_recovery command on HP-UX 11.23 on IA64 (C.6.6.93) and command fails with following output:

#make_net_recovery -s ignites -v -x inc_entire=vg00
* Creating NFS mount directories for configuration files.
* Recovery Archive Name = 2006-03-16,10:47

* Lanic Id = 0x00306E4AF4C7

* Ignite-UX Server = ignites


======= 03/16/06 10:47:38 MET Started make_net_recovery. (Thu Mar 16 10:47:38
MET 2006)
@(#) Ignite-UX Revision C.6.6.93
@(#) net_recovery (opt) $Revision: 10.750 $

* Testing for necessary pax patch.
* Passed pax tests.
* Recovery Archive Description = Recovery Archive

* Recovery Archive Location =
ignites:/var/opt/ignite/recovery/archives/myhost

* Number of Archives to Save = 2

* Pax type = tar

sh: 27672 Bus error(coredump)

** 0 - The Volume Group or Filesystem is Not included in the
System Recovery Archive
** 1 - The Volume Group or Filesystem is Partially included in the
System Recovery Archive
** 2 - The Volume Group or Filesystem is Fully included in the
System Recovery Archive

* Checking Versions of Recovery Tools

sh: 27769 Bus error(coredump)
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
0306E4AF4C7/recovery/2006-03-16,10:47/system_cfg
ERROR: A problem has been detected in determining which volume groups and/or
disks are to be part of the recovery archive. This could be due to a
failure of the "list_expander" command. Ensure that the
"/opt/ignite/lbin/list_expander" command returns valid output and
retry.

======= 03/16/06 10:47:39 MET make_net_recovery completed unsuccessfully


Please, Help me.

[Fabio Ettore]

Hi,

does list_expander command work?

Just try to launch
/opt/ignite/lbin/list_expander

Best regards,
Fabio

[BR769215]

Hi.

No, list_expander doesn't work.
It fails with coredump:

#./list_expander
Bus error(coredump)
#

Do you know what can I do with it?

[Fabio Ettore]

Hi,

that is the reason why make_net_recovery doesn't work. You should analyze the core file and if that won't help you then ask to HP support....it could be a problem in list_expander code.

Good luck...

Best regards,
Fabio

[BR769215]

Hi.

This is no problem in list_expander code, I suppose. I have another n-partitions (IA64) with HP-UX 11.23, where list_expander (and also make_net_recovery) works correctly. Both binaries (on first and second n-partiton) are identical. Ignite version on both partitions are also the same.
So, I don't know where is this problem ;-(

[Fabio Ettore]

Hi,

I agree with you it's strange that on a system list_expander works fine and on another identical system it doesn't work. I just suggested you to analyze the core as it seems a trace to follow in order to understand where the problem on list_expander is. But it is just a my thought and what I would do...

Btw good luck...

Best regards,
Fabio

[Emil Bojda]

Hi,

I upgraded Ignite-UX to version C.6.7.79 on many ia64 servers and I am returned this error on more than half of them. When I run /opt/ignite/lbin/list_expander I get the list of files, no coredumps.

=====
ERROR: The list_expander command failed. This could be due to a problem with
parsing /etc/fstab or /etc/mnttab file - see messages above.
=====

I cannot see any related "messages above" and cannot paste them here. I found the following note:

=====
http://docs.hp.com/en/B2355-90959/ch09s04.html

Note: The make_net_recovery and make_tape_recovery commands call list_expander to determine the files that will be included in a recovery archive. The following circumstance may cause list_expander to abort:

*

When processing information, list_expander uses the libc function, ftw(3C) to recursively descend the directory hierarchy (also referred to as "walking the directory").

When ftw encounters a directory containing a large number of files, all of the descendent files are processed recursively. For example, if the directory contained 400,000 files and the size of the stack frame allocated by ftw was 128 bytes, the stack size must be at least 49Mb to support the number of recursive function calls (400,000x128). In this case, it is wise to allocate additional space for other stack entries so 64Mb is a better stack size choice.

If the stack segment of the process is not large enough, list_expander is killed due to a stack growth failure. To avoid this situation, you should configure the kernel tunable maxssiz accordingly.
=====

[Adam Garsha]

I just found that if I have any mounted Vertas filesystem checkpoints that list_expander craps out. I unmounted them and I can grab my make_tape_recovery.