Error in RequiredSharedOjects results in "Failed to copy '/$LIB/liboneagentproc.so'"

[jgrumboe]

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

• ReaR version ("/usr/sbin/rear -V"):
  Relax-and-Recover 2.4 / Git

• OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
  OS_VENDOR=RedHatEnterpriseServer
  OS_VERSION=7

• ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
  OUTPUT=ISO
  BACKUP=TSM
  COPY_AS_IS_EXCLUDE_TSM=( /opt/tivoli/tsm/client/api/bin64/libTsmViSdk.so /opt/tivoli/tsm/client/ba/bin/libTsmViSdk.so /opt/tivoli/tsm/client/ba/bin/libtypes.so /opt/tivoli/tsm/client/ba/bin/libvim-types.so /opt/tivoli/tsm/client/ba/bin/plugins64/libdiskLibPlugin.so )

• Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
  vmware guest

• System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
  x86_64

• Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
  BIOS/GRUB

• Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
  local disk

• Description of the issue (ideally so that others can reproduce it):
  We have Dynatrace Oneagent for APM installed.
  The installer generates /etc/ld.so.preload with "/$LIB/liboneagentproc.so". I bet in order to
  load the correspondig 32- or 64-bit.
  We also run "rear mkrescue" each night to have a rescue ISO generated.
  On stderr we get an error "Failed to copy '/$LIB/liboneagentproc.so'".

• Workaround, if any:
  I traced it back to the function RequiredSharedOjects in lib/linux-functions.sh.
  The awk statement at the end parses ldd output for 3 different patterns.
  So with the given ld.so.preload from Dynatrace the ldd output includes a line like this:
  /$LIB/liboneagentproc.so => /lib64/liboneagentproc.so (0x00007ff999916000)
  This line matches two times in the awk statement:
  -first time here: /^\t.+ => // { print $3; }
  -second time in next line: /^\t// { print $1; } '
  I fixed it to add a "next" after each awk-print statement.
  So a line of ldd-output only matches ones and everything is fine.

• Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
  I will try to generate a pull request for this

Thanks in advance,
Johannes

[jsmeix]

@jgrumboe
thank you for finding and fixing such special cases where
the RequiredSharedObjects() function did not yet work properly.

It seems it is in particular third party tools that do very special things
with their libraries where the RequiredSharedObjects() function
is not yet prepared for. The last one of such issues was
#1980

[jsmeix]

@jgrumboe
I have a question:

I do not understand how it happens that /lib64/liboneagentproc.so
(which seems to be a library from Dynatrace Oneagent for APM)
is added to the ReaR recovery system.

I mean what is the reason behind why such a special library
for special software is needed in the ReaR recovery system?

[jgrumboe]

@jsmeix
I agree that there's no usecase for liboneagent in the recovery system. It slips right into it because it is defined in /etc/ld.so.preload and rear tries to find out automatically every required shared lib.
Probably it would be nice to have an exclude option for this, but as you said it's a very special case.

[jgrumboe]

@jsmeix and @rmetrich
Thanks for pointing me to #1980.
I tried this fix eba2b88?file-filters%5B%5D=.sh#diff-4e4a62951eec0f3018ad0193024ea158 and this also fixes my problem.

Additionally i saw that #1980 is already available under RHEL with rear-2.4-4.el7_6.
On my system i had rear-2.4-2.el7 - so i just need to upgrade.

[jsmeix]

@jgrumboe
could you attach a rear -D mkrescue debug log file
so that I could understand how exactly it happens that
/lib64/liboneagentproc.so is added to the ReaR recovery system.

[jsmeix]

Not urgent or "must have" for ReaR 2.5 so postponed to ReaR 2.6

[jsmeix]

This issue is solved according to
#2109 (comment)