Glibc 2.15 required

[oernii]

For example: on linux, glibc 2.15 is a minimum, needed for the "process_vm_readv" syscall. That excludes older linuxes unfortunately. Now the aplication just crashes:

[2022-09-21 10:58:39,701]:[INFO] - Adding open file /lib64/security/pam_namespace.so
[2022-09-21 10:58:39,705]:[INFO] - Adding open file /usr/lib64/php/modules/gd.so
[2022-09-21 10:58:39,727]:[INFO] - Adding open file /usr/local/lib/python3.6/lib-dynload/_struct.cpython-36m-x86_64-linux-gnu.so
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/varc.py", line 43, in <module>
    extract_dumps=args.extract_dumps
  File "/usr/local/lib/python3.6/site-packages/varc_core/systems/__init__.py", line 21, in acquire_system
    return LinuxSystem(include_memory, include_open, extract_dumps)
  File "/usr/local/lib/python3.6/site-packages/varc_core/systems/linux.py", line 31, in __init__
    self.process_vm_readv = self.libc.process_vm_readv
  File "/usr/local/lib/python3.6/ctypes/__init__.py", line 361, in __getattr__
    func = self.__getitem__(name)
  File "/usr/local/lib/python3.6/ctypes/__init__.py", line 366, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /lib64/libc.so.6: undefined symbol: process_vm_readv

[chrisdoman]

Thank-you @oernii !

Can you share what version of Linux you tested on please? We'll recreate. Previously I've tested on modern Debian and Alpine and it's worked, but there are likely other variants out there to check.

For context - in our build we intentionally build with the old centos7 so it is backwards compatible with older linux systems. But we can easily just add a second build pipeline on a newer distro, so you can just choose whether to run the binary compiled on "old" or "new".

[chrisdoman]

@oernii I spoke to @p-s-cott and he said:

"To address that we'll need to do one or both of: gracefully exit if you try to use varc on a version of linux that doesnt have process_vm_readv, and, add logic to check if process_vm_readv is available and if not try to use the /proc/$pid/mem approach"

We'll try to reproduce and fix. If you can let us know the OS you encountered this on, that would be useful.