Isolate the host's XDG_RUNTIME_DIR from the system tests #1652

debarshiray · 2025-05-30T23:21:35Z

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used
rootless.

First, it's important for toolbox(1) itself to work rootless because it
needs to place several files:

The lock file to synchronize Podman migrations.
The initialization stamp file to synchronize the container's entry
point with the user-facing enter and run commands running on the
host operating system.
The generated Container Device Interface specification.

These files need to be separate for the toolbox(1) processes run by the
system tests, those run by the user for normal use, and concurrent
invocations of the tests.

Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the
sandbox offered by Bats [1]. The sandbox is clearly labelled as being
used by Bats, is unique for each invocation, and Bats takes care of
cleaning everything up once it has finished running.

Note that XDG_RUNTIME_DIR's Unix access mode MUST be 0700 [2]. eg.,
Ubuntu 22.04 and 24.04 Desktop have a umask of 0002, and if an access
mode is not explicitly specified, XDG_RUNTIME_DIR will be created with
0775. That will cause dbus-daemon(1) to fail with:

  Unable to set up transient service directory: XDG_RUNTIME_DIR
      "/var/tmp/bats-run-4XQL6i/suite/xdg-runtime-dir" can be written by
      others (mode 040775)

Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus,
Pipewire and Wayland sockets from the host to the container. These
don't need to be separated. However, if a custom XDG_RUNTIME_DIR is
used then those sockets that are used by the system tests, such as the
user D-Bus socket, have to be replicated.

Therefore, a custom D-Bus instance is run to offer the user D-Bus socket
with a configuration similar to that of the host OS. The dbus-daemon(1)
implementation is used for the sake of simplicity. It creates the
socket itself based on the configuration, unlike dbus-broker-launch(1)
where the socket must be separately created and passed to it by its
parent.

However, Podman can't use systemd as the cgroups manager with this D-Bus
instance, as the bus wasn't started by the user systemd instance. So, a
custom containers.conf(5) is used to change the cgroups manager to
cgroupfs. The only other options in the containers.conf(5) are those
that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04.

[1] https://bats-core.readthedocs.io/en/stable/writing-tests.html

[2] https://specifications.freedesktop.org/basedir-spec/latest/

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html containers#1652

softwarefactory-project-zuul · 2025-05-31T01:46:32Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/49deef84c6eb43829a5488d0d59e3a53

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html containers#1652

softwarefactory-project-zuul · 2025-05-31T12:13:52Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/f149e63c2c1d491c9e8a777f1c66639e

softwarefactory-project-zuul · 2025-05-31T16:47:21Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/13442490b2d548f79b63d2cdef63b5ec

softwarefactory-project-zuul · 2025-05-31T18:28:25Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/3220d3790ac24f83a788cbaac6fa96a2

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Note that XDG_RUNTIME_DIR's Unix access mode MUST be 0700 [2]. eg., Ubuntu 22.04 Desktop has a umask of 0002, and if an access mode is not explicitly specified, XDG_RUNTIME_DIR will be created with 0775. That will cause dbus-daemon(1) to fail with: Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/tmp/bats-run-4XQL6i/suite/xdg-runtime-dir" can be written by others (mode 040775) Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html [2] https://specifications.freedesktop.org/basedir-spec/latest/ containers#1652

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Note that XDG_RUNTIME_DIR's Unix access mode MUST be 0700 [2]. eg., Ubuntu 22.04 and 24.04 Desktop have a umask of 0002, and if an access mode is not explicitly specified, XDG_RUNTIME_DIR will be created with 0775. That will cause dbus-daemon(1) to fail with: Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/tmp/bats-run-4XQL6i/suite/xdg-runtime-dir" can be written by others (mode 040775) Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html [2] https://specifications.freedesktop.org/basedir-spec/latest/ containers#1652

softwarefactory-project-zuul · 2025-06-01T00:36:13Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/b134e4a0c4954d03861ba57e35508525

debarshiray · 2025-06-01T13:32:44Z

The test suite runs fine locally on my Fedora 42 Workstation. However, it runs into problems when running on my Ubuntu 22.04 virtual machine, and on these F41, F42, Rawhide and Ubuntu 22.04 CI hosts.

As far as I can see, the problem is that podman rm --force can't kill the containers' entry points with SIGTERM. I see the same problem with podman stop.

After tracking it down through the code, I found out that the cgroup-path is empty inside the $XDG_RUNTIME_DIR/crun/$CONTAINER_ID/status file. This is likely causing crun kill --all to silently fail with a successful exit code.

softwarefactory-project-zuul · 2025-06-01T15:25:06Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/a585724c1d7e42c4b85120ed204179cf

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Jsut like Flatpak, the singleton 'p11-kit server' process is not terminated, when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Jsut like Flatpak, the singleton 'p11-kit server' process is not terminated, when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Just like Flatpak, the singleton 'p11-kit server' process is not terminated, when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Just like Flatpak, the singleton 'p11-kit server' process is not terminated when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

Fallout from the following: * f5bf741 * 2edc308 * 872eba4 * 8b6418d * b166a1f * 0000cb0 containers#1677

Fallout from d323143 containers#1677

... at https://containertoolbx.org/install/ This should have been part of commit df22010. containers#1678

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Note that XDG_RUNTIME_DIR's Unix access mode MUST be 0700 [2]. eg., Ubuntu 22.04 and 24.04 Desktop have a umask of 0002, and if an access mode is not explicitly specified, XDG_RUNTIME_DIR will be created with 0775. That will cause dbus-daemon(1) to fail with: Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/tmp/bats-run-4XQL6i/suite/xdg-runtime-dir" can be written by others (mode 040775) Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html [2] https://specifications.freedesktop.org/basedir-spec/latest/ containers#1652

softwarefactory-project-zuul · 2025-07-04T19:44:45Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/containers/toolbox for 1652,59bcef01cb27023cc214ccd5f773cacca47fd1d1

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Note that XDG_RUNTIME_DIR's Unix access mode MUST be 0700 [2]. eg., Ubuntu 22.04 and 24.04 Desktop have a umask of 0002, and if an access mode is not explicitly specified, XDG_RUNTIME_DIR will be created with 0775. That will cause dbus-daemon(1) to fail with: Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/tmp/bats-run-4XQL6i/suite/xdg-runtime-dir" can be written by others (mode 040775) Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html [2] https://specifications.freedesktop.org/basedir-spec/latest/ containers#1652

softwarefactory-project-zuul · 2025-07-04T19:53:01Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/containers/toolbox for 1652,780a208d8c357dfd8f4eeebc1000af71b7c734d9

XDG_RUNTIME_DIR is needed for two groups of reasons when Toolbx is used rootless. First, it's important for toolbox(1) itself to work rootless because it needs to place several files: * The 'lock' file to synchronize Podman migrations. * The initialization stamp file to synchronize the container's entry point with the user-facing 'enter' and 'run' commands running on the host operating system. * The generated Container Device Interface specification. These files need to be separate for the toolbox(1) processes run by the system tests, those run by the user for 'normal' use, and concurrent invocations of the tests. Therefore, it's better to use a custom XDG_RUNTIME_DIR that's within the sandbox offered by Bats [1]. The sandbox is clearly labelled as being used by Bats, is unique for each invocation, and Bats takes care of cleaning everything up once it has finished running. Note that XDG_RUNTIME_DIR's Unix access mode MUST be 0700 [2]. eg., Ubuntu 22.04 and 24.04 Desktop have a umask of 0002, and if an access mode is not explicitly specified, XDG_RUNTIME_DIR will be created with 0775. That will cause dbus-daemon(1) to fail with: Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/tmp/bats-run-4XQL6i/suite/xdg-runtime-dir" can be written by others (mode 040775) Second, XDG_RUNTIME_DIR is used to propagate things like the user D-Bus, Pipewire and Wayland sockets from the host to the container. These don't need to be separated. However, if a custom XDG_RUNTIME_DIR is used then those sockets that are used by the system tests, such as the user D-Bus socket, have to be replicated. Therefore, a custom D-Bus instance is run to offer the user D-Bus socket with a configuration similar to that of the host OS. The dbus-daemon(1) implementation is used for the sake of simplicity. It creates the socket itself based on the configuration, unlike dbus-broker-launch(1) where the socket must be separately created and passed to it by its parent. However, Podman can't use systemd as the cgroups manager with this D-Bus instance, as the bus wasn't started by the user systemd instance. So, a custom containers.conf(5) is used to change the cgroups manager to cgroupfs. The only other options in the containers.conf(5) are those that are common across Fedora 41 and 42, and Ubuntu 22.04 and 24.04. [1] https://bats-core.readthedocs.io/en/stable/writing-tests.html [2] https://specifications.freedesktop.org/basedir-spec/latest/ containers#1652

softwarefactory-project-zuul · 2025-07-04T20:54:39Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/7220c11bd5054073864afc49e5f3cbde

debarshiray requested a review from Jmennius as a code owner May 30, 2025 23:21

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 37bf2b2 to 3e7623b Compare May 30, 2025 23:46

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch 2 times, most recently from 946f684 to 9d5974c Compare May 31, 2025 01:09

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch 7 times, most recently from 2d66773 to 6e370af Compare May 31, 2025 11:06

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch 6 times, most recently from b0def84 to 4953ac1 Compare May 31, 2025 15:12

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 4953ac1 to 5eb3709 Compare May 31, 2025 17:02

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 5eb3709 to 7149cb5 Compare May 31, 2025 21:57

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch 2 times, most recently from fdfb530 to 27ce2e5 Compare June 1, 2025 00:07

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 27ce2e5 to 92aa22b Compare June 1, 2025 13:22

debarshiray mentioned this pull request Jun 1, 2025

Give access to the CA certificates from the host #1644

Merged

debarshiray added 3 commits July 4, 2025 21:01

pkg/utils: Style fixes

62712d7

Fallout from the following: * f5bf741 * 2edc308 * 872eba4 * 8b6418d * b166a1f * 0000cb0 containers#1677

pkg/utils: Remove unused functions

fb43d3e

Fallout from d323143 containers#1677

playbooks: Use the same commands as mentioned in the documentation

2099190

... at https://containertoolbx.org/install/ This should have been part of commit df22010. containers#1678

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 92aa22b to 59bcef0 Compare July 4, 2025 19:44

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 59bcef0 to 780a208 Compare July 4, 2025 19:52

debarshiray added 2 commits July 4, 2025 22:25

debug

1c616f0

debarshiray force-pushed the wip/rishi/test-system-libs-helpers-isolate-xdg-runtime-dir branch from 780a208 to 1c616f0 Compare July 4, 2025 20:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Isolate the host's XDG_RUNTIME_DIR from the system tests #1652

Isolate the host's XDG_RUNTIME_DIR from the system tests #1652

Uh oh!

debarshiray commented May 30, 2025 •

edited

Loading

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jun 1, 2025

Uh oh!

debarshiray commented Jun 1, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jun 1, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 4, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 4, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 4, 2025

Uh oh!

Uh oh!

Isolate the host's XDG_RUNTIME_DIR from the system tests #1652

Are you sure you want to change the base?

Isolate the host's XDG_RUNTIME_DIR from the system tests #1652

Uh oh!

Conversation

debarshiray commented May 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented May 31, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jun 1, 2025

Uh oh!

debarshiray commented Jun 1, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jun 1, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 4, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 4, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 4, 2025

Uh oh!

Uh oh!

debarshiray commented May 30, 2025 •

edited

Loading