summaryrefslogtreecommitdiff
path: root/pkgs/development/python-modules/debugpy/fix-test-pythonpath.patch
diff options
context:
space:
mode:
authoraszlig <aszlig@nix.build>2025-11-24 19:16:34 +0100
committeraszlig <aszlig@nix.build>2025-12-05 16:52:08 +0100
commit270601f6c466bf0cf5bc76197254492ef31a7aaa (patch)
tree67ae6c4f3b115a9fb86abcb13011015b1183f296 /pkgs/development/python-modules/debugpy/fix-test-pythonpath.patch
parent52be777193b0e75ee664b2e686b74b2e3c05de79 (diff)
nixos/systemd-confinement: Fix with template units
Quoting from <https://github.com/NixOS/nixpkgs/issues/464323>: > When using confinement.enable = true for an instanced systemd service, > the 2nd instance will fail to start if the 1st instance is still > running. > > This only happens with confinement.enable = true;. Removing this > option causes both service instances to succeed. Maybe this happens > because the /run/confinement/fortune directory is shared between the > instances. The reason why this happens is that the root directory is set to "/run/confinement/${mkPathSafeName name}", which is the non-expanded unit name rather than the full unit name with the instance in case of a template unit. So when a template unit "foo@.service" is involved, the root directory is then "/run/confinement/foo_" regardless of instance, so foo@bar.service uses the same directory as foo@baz.service and when the first unit cleans up the root directory, it also makes it inaccessible for the unit started afterwards. I added a small property test to test concurrent invocations, so we cover this case and other issues that might come up with template units in a future refactor. Signed-off-by: aszlig <aszlig@nix.build>
Diffstat (limited to 'pkgs/development/python-modules/debugpy/fix-test-pythonpath.patch')
0 files changed, 0 insertions, 0 deletions