AIX Open Source

 View Only

 Clamd ERROR,"Can't allocate memory ERROR"

直也 酒井's profile image
直也 酒井 posted Mon June 30, 2025 01:50 AM

Hello everyone,
I would like to consult with you regarding an error that I have encountered while scanning with ClamAV 1.0.7 on AIX 7.3, particularly with clamd, which is not something I have encountered often.

On multiple AIX servers that I support for management, an occurrence happened where, at almost the same timing when files were scanned by clamd, all the scans recorded a "Can't allocate memory ERROR" and failed as follows;
Fri Jun 27 18:24:10 2025 -> /opt/app/bin: Can't allocate memory ERROR
Fri Jun 27 18:24:10 2025 -> /opt/app/bin/a.out: Can't allocate memory ERROR
Fri Jun 27 18:24:10 2025 -> /opt/app/bin/check.sh: Can't allocate memory
ERROR
Fri Jun 27 18:24:10 2025 -> /opt/app/bin/data01: Can't allocate memory ERROR
Fri Jun 27 18:24:10 2025 -> /opt/app/bin/upd.sh: Can't allocate memory ERROR
Fri Jun 27 18:24:10 2025 -> /opt/app/contrib/.subsystem: Can't allocate
memory ERROR
Fri Jun 27 18:24:10 2025 -> /opt/app/contrib/user.conf: Can't allocate
memory ERROR

I remember that in former versions of ClamAV, similar errors occurred with certain file formats.
Also, I have encountered situations where clamd failed to start in a memory-constrained environment or shut down during scanning several times.

However, in this environment, the server has 32GB of memory, and about 10GB of free memory is secured according to svmon.
The scan targets include simple text files of just a few KB as well as program files of several MB, but they do not include archives or large files.
The same "Can't allocate memory ERROR" has occurred for all files that were scanned, without exception.

I am not well-versed in the internal structure of clamd, but I understand that clamd operates in a multi-threaded manner during object scanning (it launches new threads and assigns them to scanning), so I checked the ulimit settings for AIX threads and processes, as well as memory.

 ulimit -a
 time(seconds)        unlimited
 file(blocks)         unlimited
 data(kbytes)         unlimited
 stack(kbytes)        4194304
 memory(kbytes)       unlimited
 coredump(blocks)     2097151
 nofiles(descriptors) 8000
 threads(per process) unlimited
 processes(per user)  16384

Looking at this, it doesn't seem that any particularly problematic values are set.
What could be the reasons for clamd returning this kind of error for all scan requests?

Thank you in advance.

Aditya Kamath's profile image
Aditya Kamath posted Mon June 30, 2025 03:41 AM

Hi,

Someone else also faced a similar issue here.

But that may not be the root cause for your issue. 

Former versions of ClamAV faced issues when bin format files were existing, which we have fixed. 

Also paste me the rpm -qa | grep clamavoutput. 

Also, what is the size of /opt/app/bin? Before we go into other details, can you share the answer to these two?

直也 酒井's profile image
直也 酒井 posted Mon June 30, 2025 04:59 AM

Thank you for your reply.

The link you provided was what my colleague inquired about here previously.
I remember this case.

The |rpm -qa | grep clamav|output is as follows;

# rpm -qa | grep clamav
clamav-1.0.7-2.ppc


The size of /opt/app/bin is as follows;

# du -m /opt/app/bin
1.71    /opt/app/bin 

Aditya Kamath's profile image
Aditya Kamath posted Mon June 30, 2025 05:07 AM

Can you try updating to 1.0.7-3 and check?? We did fix one issue in ClamAV. 

直也 酒井's profile image
直也 酒井 posted Mon June 30, 2025 07:40 PM

Thank you for your reply.
I updated ClamAV to clamav-1.0.7-3, but there was no change in the situation;

Mon Jun 30 19:23:59 2025 -> /opt/app/bin/data01: Can't allocate memory ERROR
Mon Jun 30 19:23:59 2025 -> /opt/app/bin/upd.sh: Can't allocate memory ERROR
Mon Jun 30 19:23:59 2025 -> /opt/app/contrib/.subsystem: Can't allocate memory ERROR
Mon Jun 30 19:23:59 2025 -> /opt/app/contrib/user.conf: Can't allocate memory ERROR

Aditya Kamath's profile image
Aditya Kamath posted Tue July 01, 2025 01:23 AM

Hmm, so we need to identify the root cause since we are not able to reproduce the issue in our tests.

To support, we need more information.

The ulimit -d is set so that is ruled out.

1: Have you set any MaxDataSize, MaxFileSize, or MaxRecursion in clamd.conf? If yes, how much is that?

2: Can you run the scan let's say clamscan /opt/app/bin/data01

and then simultaneously paste the outputs of lsps -a and vmstat 1 10?

3: Also, vmstat -v will be useful.

We want to see if memory issues indeed exist. If while running clamd you see something like 95%+ use in lsps -a, then it might be the root cause.

Let me know before we can go into other things.

直也 酒井's profile image
直也 酒井 posted Tue July 01, 2025 11:53 PM

Thank you for your reply.

We are currently preparing to obtain these data.
Meanwhile, I received the following feedback from the ClamAV-Users ML regarding the same issue;

"I am not using AIX, so I cannot give detailed advice, but I have encountered a similar error in the past with RHEL 8/9 where FIPS support was enabled on the OS.
Discussions are being held at the following URL.
https://github.com/Cisco-Talos/clamav/issues/564 "

Indeed, looking at the page, the message "|ERROR: Can't allocate memory|" occurs regardless of whether there are sufficient resources on the OS, and it is said that the cause lies in the use of the MD5 hash, so it is suspected that this issue may be applicable to what is happening this time.
However, I am not sure whether something called 【FIPS mode】 is implemented in AIX.
Is there a mode that imposes such restrictions in AIX 7.3?
I would appreciate it if you could let me know.

Aditya Kamath's profile image
Aditya Kamath posted Wed July 02, 2025 02:51 AM

I am checking if that is true. Can you tell me in your LPAR what is the output of openssl version -a

直也 酒井's profile image
直也 酒井 posted Wed July 02, 2025 04:47 AM

Thank you for your reply.



[root@sv1 ]# openssl version -a
OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)
built on: Thu Nov 23 18:35:31 2023 UTC
platform: aix-xlc_r
options:  bn(64,32)
compiler: xlc_r -qpic -q32 -qmaxmem=16384 -qro -qroconst -qthreaded -O -DB_ENDIAN -DOPENSSL_PIC -D_THREAD_SAFE -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -DSSL_ALLOW_ADH -DAIXSSL_IBM_VERSION=3.0.10.1002
OPENSSLDIR: "/var/ssl"
ENGINESDIR: "/usr/lib/engines-3"
MODULESDIR: "/usr/lib/ossl-modules/32"
Seeding source: os-specific
CPUINFO: N/A
直也 酒井's profile image
直也 酒井 posted Wed July 02, 2025 08:13 PM
 
> 1: Have you set any MaxDataSize, MaxFileSize, or MaxRecursion in
> clamd.conf? If yes, how much is that?
 
Those settings have not been made.
All those settings are 0.
 
> 2: Can you run the scan let's say |clamscan /opt/app/bin/data01|
> and then simultaneously paste the outputs of |lsps -a| and |vmstat 1 10|?
 
The outputs is;
 
# lsps -a
Page Space      Physical Volume   Volume Group    Size %Used Active Auto    Type   Chksum
hd6             hdisk0 rootvg       24576MB     0     yes     yes lv       0
 
[root@psysbkt1 /]# vmstat 1 10
 
System configuration: lcpu=32 mem=16384MB
 
kthr    memory              page              faults        cpu    
----- ----------- ------------------------ ------------ -----------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa
 1  0 1105330 2617618   0   0   0   0    0   0 139 3703 538  7  0 92  0
 1  0 1105330 2617618   0   0   0   0    0   0   0   30 207  7  0 93  0
 1  0 1106178 2616770   0   0   0   0    0   0   2 1674 269  7  0 92  0
 1  0 1108680 2614268   0   0   0   0    0   0   8  376 248  7  0 93  0
 1  0 1108689 2614257   0   0   0   0    0   0 108 2786 408  8  0 92  0
 1  0 859802 2863144   0   0   0   0    0   0 119 5262 556  5  2 93  0
 0  0 762953 2959993   0   0   0   0    0   0   7 2006 226  0  1 99  0
 0  0 762898 2960048   0   0   0   0    0   0   4 3373 412  0  0 99  0
 0  0 762898 2960051   0   0   0   0    0   0   5   37 289  0  0 99  0
 0  0 762898 2960051   0   0   0   0    0   0   0   31 214  0  0 99  0
 
[root@psysbkt1 /]# vmstat -v
              4194304 memory pages
              4050336 lruable pages
              2779718 free pages
                    4 memory pools
               666967 pinned pages
                 90.0 maxpin percentage
                  3.0 minperm percentage
                 90.0 maxperm percentage
                 11.3 numperm percentage
               458816 file pages
                  0.0 compressed percentage
                    0 compressed pages
                 11.3 numclient percentage
                 90.0 maxclient percentage
               458816 client pages
                    0 remote pageouts scheduled
                    0 pending disk I/Os blocked with no pbuf
                    0 paging space I/Os blocked with no psbuf
                 1400 filesystem I/Os blocked with no fsbuf
                   12 client filesystem I/Os blocked with no fsbuf
                    0 external pager filesystem I/Os blocked with no fsbuf
                 22.8 percentage of memory used for computational pages
 
When scanned with clamscan, unlike when using clamd, the scan completed successfully without any errors. 
Aditya Kamath's profile image
Aditya Kamath posted Fri July 04, 2025 01:25 AM

Hi,

I have been trying to reproduce the issue but have not succeeded so far. 

We do test running using the daemon clamd, but we did not face any issues. 

If you are able to run clamscan in the same directory in the foreground, then the root cause is something else while running the daemon. May I ask, are you running the daemon as a non-root user? Where there is a chance that the user is having a limited number of resources via ulimit?

Your LPAR has enough memory, looking at the data shown.

Regarding FIPS mode in AIX. Yes, we do have it in AIX. But for that we need to do changes in /var/ssl/openssl.cnf which we did not do when we compiled clamav. Did you make any changes to /var/ssl/openssl.cnf ?

Related Content