test: make the MemoryHigh= limit a bit more generous with sanitizers

When we're running with sanitizers, sd-executor might pull in a
significant chunk of shared libraries on startup, that can cause a lot
of memory pressure and put us in the front when sd-oomd decides to go on
a killing spree. This is exacerbated further on Arch Linux when built
with gcc, as Arch ships unstripped gcc-libs so sd-executor pulls in over
30M of additional shared libs on startup:

~# lddtree build-san/systemd-executor
build-san/systemd-executor (interpreter => /lib64/ld-linux-x86-64.so.2)
    libasan.so.8 => /usr/lib/libasan.so.8
        libstdc++.so.6 => /usr/lib/libstdc++.so.6
        libm.so.6 => /usr/lib/libm.so.6
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
    libsystemd-core-255.so => /root/systemd/build-san/src/core/libsystemd-core-255.so
        libaudit.so.1 => /usr/lib/libaudit.so.1
            libcap-ng.so.0 => /usr/lib/libcap-ng.so.0
...
    libseccomp.so.2 => /usr/lib/libseccomp.so.2
    libubsan.so.1 => /usr/lib/libubsan.so.1
    libc.so.6 => /usr/lib/libc.so.6

~# ls -Llh /usr/lib/libasan.so.8 /usr/lib/libstdc++.so.6 /usr/lib/libubsan.so.1
-rwxr-xr-x 1 root root 9.7M Feb  2 10:36 /usr/lib/libasan.so.8
-rwxr-xr-x 1 root root  21M Feb  2 10:36 /usr/lib/libstdc++.so.6
-rwxr-xr-x 1 root root 3.2M Feb  2 10:36 /usr/lib/libubsan.so.1

Sanitized libsystemd-core.so is also quite big:

~# ls -Llh /root/systemd/build-san/src/core/libsystemd-core-255.so /usr/lib/systemd/libsystemd-core-255.so
-rwxr-xr-x 1 root root  26M Feb  8 19:04 /root/systemd/build-san/src/core/libsystemd-core-255.so
-rwxr-xr-x 1 root root 5.9M Feb  7 12:03 /usr/lib/systemd/libsystemd-core-255.so

diff --git a/test/units/testsuite-55.sh b/test/units/testsuite-55.sh
index afd3053e4da5bbd14099d09640192c7720be9430..251a7723038f74bc178436552e398d698a134b9f 100755 (executable)
--- a/test/units/testsuite-55.sh
+++ b/test/units/testsuite-55.sh
@@ -71,9 +71,22 @@ if systemctl is-active systemd-oomd.service; then
     systemctl restart systemd-oomd.service
 fi
 
-# Ensure that we can start services even with a very low hard memory cap without oom-kills, but skip under
-# sanitizers as they balloon memory usage.
-if ! [[ -v ASAN_OPTIONS || -v UBSAN_OPTIONS ]]; then
+if [[ -v ASAN_OPTIONS || -v UBSAN_OPTIONS ]]; then
+    # If we're running with sanitizers, sd-executor might pull in quite a significant chunk of shared
+    # libraries, which in turn causes a lot of pressure that can put us in the front when sd-oomd decides to
+    # go on a killing spree. This fact is exacerbated further on Arch Linux which ships unstripped gcc-libs,
+    # so sd-executor pulls in over 30M of libs on startup. Let's make the MemoryHigh= limit a bit more
+    # generous when running with sanitizers to make the test happy.
+    systemctl edit --runtime --stdin --drop-in=99-MemoryHigh.conf testsuite-55-testchill.service <<EOF
+[Service]
+MemoryHigh=60M
+EOF
+    # Do the same for the user instance as well
+    mkdir -p /run/systemd/user/
+    cp -rfv /run/systemd/system/testsuite-55-testchill.service.d/ /run/systemd/user/
+else
+    # Ensure that we can start services even with a very low hard memory cap without oom-kills, but skip
+    # under sanitizers as they balloon memory usage.
     systemd-run -t -p MemoryMax=10M -p MemorySwapMax=0 -p MemoryZSwapMax=0 /bin/true
 fi