Hi,

I am getting the same output on a fresh RHEL 8.7 virtual machine. But I think that the output is expected and isn't a bug. The errors are caused by insufficient permissions of the user, oscap can't read some system configuration files. In general, we recommend to run oscap with sudo or with root privileges. 

The details can be found in the HTML report (add "--report report.html" to the command to generate a HTML report) or in the ARF file (the --results-arf option).

Can you elaborate why you think that you have a memory related issue? Is your experience different on systems with more memory?

Also, can you try to run the oscap with sudo or as root user? Please share the results here.

Hello Benjamin, could you check the page on our official RHEL documentation if it answers your question? I understand the configuration you use is below minimal required system specs.

https://access.redhat.com/articles/rhel-limits

1. Everything tested has been run as the root user, so there is no permissions issue.
2. Please see my previous instructions on adding 2GB of swap in the work-around section.  This resolved the issue immediately with no other changes.  The issue was consistently reproducible until I increased the memory in the system.
3. The memory in the system is below the minimum as per the link you shared, BUT in AWS users are able to deploy instances with 1GiB of memory or less, which is below that requirement.  This is contradictory information in a broader RHEL sense.

I just re-tested using the following command and got the attached results

```
[root@node2 ~]# oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_e8 --report report.html --results-arf results.arf --results scan.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
WARNING: Datastream component 'scap_org.open-scap_cref_security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2' points out to the remote 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2'. Use '--fetch-remote-resources' option to download it.
WARNING: Skipping 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2' file which is referenced from datastream
WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 file which is referenced from XCCDF content
--- Starting Evaluation ---

etc...

Rule    xccdf_org.ssgproject.content_rule_sshd_set_loglevel_info
Ident   CCE-82282-5
Result  fail




Killed

```

So in the above it just said "killed" which is different to the output from before now that i have added --result-arf and --report report.html, which is interesting.  I then went to install tmux so I could monitor memory usage whilst running the command again, and got this:

```
[root@node2 ~]# yum install tmux
Updating Subscription Management repositories.
Last metadata expiration check: 2:34:54 ago on Thu 24 Nov 2022 19:37:55 UTC.
Dependencies resolved.
=========================================================================================================================
 Package             Architecture          Version                    Repository                                    Size
=========================================================================================================================
Installing:
 tmux                x86_64                2.7-1.el8                  rhel-8-for-x86_64-baseos-rpms                317 k

Transaction Summary
=========================================================================================================================
Install  1 Package

Total download size: 317 k
Installed size: 770 k
Is this ok [y/N]: y
Downloading Packages:
tmux-2.7-1.el8.x86_64.rpm                                                                458 kB/s | 317 kB     00:00    
-------------------------------------------------------------------------------------------------------------------------
Total                                                                                    411 kB/s | 317 kB     00:00     
[Errno 12] Cannot allocate memory
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'yum clean packages'.
[root@node2 ~]# 
```

Then I check the memory:
```
[root@node2 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:            776         203         283           5         289         451
Swap:             0           0           0
[root@node2 ~]# 

```

I am quite confident that the system is running out of memory during the scan, and in this instance didn't clean up when it was "killed".

Thanks for clarification.

I'm sorry I was confused by the output you pasted in the bug description (http://pastebin.test.redhat.com/1082609) where oscap is run under non-root user without sudo and where the output doesn't contain anything unexpected.

From your latest comment, I see it's definitely a memory issue, when you run as root you get the correct "fail" rule result, but then the process is killed during generation of XML/HTML results. If the system is below minimum required memory, it doesn't have enough memory to be able to transform the results to XML.

We have seen this problem in past, we have workarounds for some situations. For example in https://bugzilla.redhat.com/show_bug.cgi?id=1829782 it was triggered by too many files on the file system and in the release note we suggested to remove some rules that are data intensive. But in our team we don't see any quick solution, we have a conclusion that the overall design of the openscap tool isn't memory-friendly.

No problem Jan.  I was using output captured by Marek for your reference, but my results were the same when I had tested via `sudo -i`.  If oscap is memory intensive, then do you think this should become a documentation issue?  Having said all of that, should the initial basic version of the command output something more meaningful when it fails mid-run rather than just stopping with no useful info?

*** This bug has been marked as a duplicate of bug 2161499 ***

This bug boils down to the outstanding memory problems of OpenSCAP which are covered by the KBS https://access.redhat.com/articles/6999111 and that are unlikely to be fixed.