docker-mailserver/test/tests/serial/no_container.bats

29 lines
1.2 KiB
Plaintext
Raw Normal View History

load "${REPOSITORY_ROOT}/test/helper/setup"
load "${REPOSITORY_ROOT}/test/helper/common"
# ! ATTENTION: Must be run in serial mode, as no existing containers should be present.
# Tests the `setup.sh` companion script.
# Only test coverage below is that the config path `-p` and image `-i` options work as intended.
BATS_TEST_NAME_PREFIX='[No Existing Container] '
tests: Ensure excessive FD limits are avoided (#2730) * tests: Ensure excessive FD limits are avoided Processes that run as daemons (`postsrsd` and `fail2ban-server`) initialize by closing all FDs (File Descriptors). This behaviour queries that maximum limit and iterates through the entire range even if only a few FDs are open. In some environments (Docker, limit configured by distro) this can be a range exceeding 1 billion (from kernel default of 1024 soft, 4096 hard), causing an 8 minute delay with heavy CPU activity. `postsrsd` has since been updated to use `close_range()` syscall, and `fail2ban` will now iterate through `/proc/self/fd` (open FDs) which should resolve the performance hit. Until those updates reach our Docker image, we need to workaround it with `--ulimit` option. NOTE: If `docker.service` on a distro sets `LimitNOFILE=` to approx 1 million or lower, it should not be an issue. On distros such as Fedora 36, it is `LimitNOFILE=infinity` (approx 1 billion) that causes excessive delays. * chore: Use Docker host limits instead Typically on modern distros with systemd, this should equate to 1024 (soft) and 512K (hard) limits. A distro may override the built-in global defaults systemd sets via setting `DefaultLimitNOFILE=` in `/etc/systemd/user.conf` and `/etc/systemd/system.conf`. * tests(fix): Better prevent non-deterministic failures - `no_containers.bats` tests the external script `setup.sh` (without `-c`). It's expected that no existing DMS container is running - otherwise it may attempt to use that container and fail. Detect this and fail early via `setup_file()` step. - `mail_hostname.bats` had a odd timing failure with teardown due to the last tests bringing the containers down earlier (`docker stop` paired with the `docker run --rm`). Adding a moment of delay via `sleep` helps avoid that false positive scenario.
2022-08-22 23:24:23 +00:00
function setup_file() {
# Fail early if the testing image is already running:
assert_not_equal "$(docker ps | grep -o "${IMAGE_NAME}")" "${IMAGE_NAME}"
# Copy the base config that `setup.sh` will volume mount to a container it runs:
export TEST_TMP_CONFIG
TEST_TMP_CONFIG=$(_duplicate_config_for_container . 'no_container')
}
@test "'setup.sh -p <PATH> -i <IMAGE>' should correctly use options" {
# Create a `postfix-virtual.cf` config to verify the container can access it:
local MAIL_ALIAS='no_container@example.test no_container@forward.test'
echo "${MAIL_ALIAS}" > "${TEST_TMP_CONFIG}/postfix-virtual.cf"
# Should run the testing image with a volume mount to the provided path:
run ./setup.sh -p "${TEST_TMP_CONFIG}" -i "${IMAGE_NAME}" alias list
assert_success
assert_output --partial "* ${MAIL_ALIAS}"
tests: Ensure excessive FD limits are avoided (#2730) * tests: Ensure excessive FD limits are avoided Processes that run as daemons (`postsrsd` and `fail2ban-server`) initialize by closing all FDs (File Descriptors). This behaviour queries that maximum limit and iterates through the entire range even if only a few FDs are open. In some environments (Docker, limit configured by distro) this can be a range exceeding 1 billion (from kernel default of 1024 soft, 4096 hard), causing an 8 minute delay with heavy CPU activity. `postsrsd` has since been updated to use `close_range()` syscall, and `fail2ban` will now iterate through `/proc/self/fd` (open FDs) which should resolve the performance hit. Until those updates reach our Docker image, we need to workaround it with `--ulimit` option. NOTE: If `docker.service` on a distro sets `LimitNOFILE=` to approx 1 million or lower, it should not be an issue. On distros such as Fedora 36, it is `LimitNOFILE=infinity` (approx 1 billion) that causes excessive delays. * chore: Use Docker host limits instead Typically on modern distros with systemd, this should equate to 1024 (soft) and 512K (hard) limits. A distro may override the built-in global defaults systemd sets via setting `DefaultLimitNOFILE=` in `/etc/systemd/user.conf` and `/etc/systemd/system.conf`. * tests(fix): Better prevent non-deterministic failures - `no_containers.bats` tests the external script `setup.sh` (without `-c`). It's expected that no existing DMS container is running - otherwise it may attempt to use that container and fail. Detect this and fail early via `setup_file()` step. - `mail_hostname.bats` had a odd timing failure with teardown due to the last tests bringing the containers down earlier (`docker stop` paired with the `docker run --rm`). Adding a moment of delay via `sleep` helps avoid that false positive scenario.
2022-08-22 23:24:23 +00:00
}