Adjust memory limit check in docker env

[realFlowControl]

In a CircleCI environment when running tests in docker and limited to a medium instance (4GB memory limit), free and /proc/meminfo are not reflecting the memory limit of the container, but the host:

$ cat /proc/meminfo 
MemTotal:       71898492 kB
MemFree:         8905616 kB
...
$ free -h
              total        used        free      shared  buff/cache   available
Mem:           68Gi        19Gi       3.0Gi       306Mi        46Gi        48Gi
Swap:            0B          0B          0Bree

MemFree in this case with ~8.9GB prevents the execution of the test, but depending on the order of execution and maybe other jobs on that host, MemFree sometimes is above the 10GB threshold. This will lead to the test being started and then OOM killed.

So in case we run in docker, we need to check the cgroup memory limit:

$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes
4294967296

Related to #13203

[staabm]

do we need something similar for other tests:
https://github.com/search?q=repo%3Aphp%2Fphp-src%20proc%2Fmeminfo&type=code

maybe the logic should be extracted for re-use ?

[staabm]

maybe it would be even worth it to create a new php-src function which works on docker and regular unix?
that way the php-src tests could be simplified and php userland would also benefit

[realFlowControl]

Thats both a good idea IMHO, I'll create a separate PR for the other tests, once we have this one settled.

[bukka]

Just tried locally on Ubuntu 20.04 with Docker version 26.1.3 and getting a bit nonsense there:

docker run -ti nginx:alpine sh
/ # cat /sys/fs/cgroup/memory/memory.limit_in_bytes
9223372036854771712

So not sure if this is always working in Docker...

[bukka]

Forgot to provide kernel version: 5.15.0-113-generic

[realFlowControl]

@bukka could you do me a favour and run with docker run -ti --memory 512m nginx:alpine sh and check again?
It looks like this is way more complex than I initially thought 😉
So the current theory is: you are on Linux 5, using cgroup v1 which exposes /sys/fs/cgroup/memory/memory.limit_in_bytes, cgroup v2 will instead expose /sys/fs/cgroup/memory.max for example, that holds either the string max in case there is no memory limit or an integer representing the memory limit in bytes.

Btw.: 9223372036854771712 represents "no limit" for a 64-bit machine according to https://unix.stackexchange.com/a/421182

[bukka]

Yeah this works. So I think this should be just an additional check and not primary check for docker.

[bukka]

What I mean is that the skip should first check the meminfo and if that is ok, then check the Docker one if on Docker. Would it maybe make sense to not limit on docker but always check /sys/fs/cgroup/memory/memory.limit_in_bytes if present?

[realFlowControl]

Hey @bukka,
can you have another look? Looks good for me now.

[nielsdos]

Hm, I copied the code already in 9435f4d#diff-8689e5b00cb8d845b3d27ac0094c9342d5cde859d0a6defa39147d23e18459c7R12 before I noticed this PR.
Probably, this should be factored out to a common helper file as cmb noted on the ML.

[bukka]

I'm wondering if it would make sense to introduce section in run-tests for this. It might be more consistent but won't work when run directly so I guess I'm fine with both approaches.

[realFlowControl]

Look at this, sapi/cli/tests/upload_2G.phpt is failing on Windows. From how the --SKIPIF-- section looked before this change, this test was always skipped in Windows. I could change it to behave like this again, but I was wondering if this should work. Also I have no experience with PHP on Windows, maybe @cmb69 has an idea whats going on?

========DIFF========
     Test
002- HTTP/1.1 200 OK
003- Host: %s
004- Date: %s
005- Connection: close
006- X-Powered-By: PHP/%s
007- Content-type: text/html; charset=UTF-8
     
003+ Notice: fwrite(): Send of 100000 bytes failed with errno=10035 A non-blocking socket operation could not be completed immediately in D:\a\php-src\php-src\sapi\cli\tests\upload_2G.php on line 34
004+ write failed @ ([98](https://github.com/php/php-src/actions/runs/10555691715/job/29239745310?pr=14895#step:6:99)6900000)
009- array(1) {
010-   ["file1"]=>
011-   array(6) {
012-     ["name"]=>
013-     string(9) "file1.txt"
014-     ["full_path"]=>
015-     string(9) "file1.txt"
016-     ["type"]=>
017-     string(10) "text/plain"
018-     ["tmp_name"]=>
019-     string(%d) "%s"
020-     ["error"]=>
021-     int(0)
022-     ["size"]=>
023-     int(2150000000)
024-   }
025- }
026- Done
========DONE========
FAIL file upload greater than 2G [D:\a\php-src\php-src\sapi\cli\tests\upload_2G.phpt]

[cmb69]

Look at this, sapi/cli/tests/upload_2G.phpt is failing on Windows.

I guess that is an issue with the internal buffering and the pipe manager; I would need to check this, but that may take a while (backlog too long).