Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Error] Hitting thread / process resource limits in systemd container #1183

Closed
sir-yells-alot opened this issue Feb 1, 2024 · 1 comment
Closed
Labels
bug Something isn't working

Comments

@sir-yells-alot
Copy link

Description
Trying to create more than ~400 processes / threads fails

To Reproduce

distrobox create --name test --init --image quay.io/archlinux/archlinux:latest --additional-packages "systemd"
distrobox enter test
for i in {1..400} ; do ( sleep 1 & ); done

Error:
bash: fork: retry: Resource temporarily unavailable

Expected behavior
Bash does not fail to create more than ~400 processes

Logs
distrobox-test.log
podman-logs.log

Desktop:
Using podman version 4.9.0
Using distrobox version 1.6.0.1
On: NixOS 24.05 (Uakari) & unstable packages
Distrobox was installed with the installation scripts into ~/.local

Additional context
I'm not entirely sure if it is resource limits, but it seems to have something to do with the distrobox enter command putting your shell in init.scope

[siryellsalot@test ~]$ systemctl status
● test.gengar
    State: running
    Units: 554 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2024-02-01 22:26:37 UTC; 11min ago
  systemd: 255.3-1-arch
   CGroup: /
           ├─init.scope
           │ ├─   1 /usr/lib/systemd/systemd --system --log-target=console --unit=multi-user.target
           │ ├─ 951 script -c "cat /var/console" /dev/null
           │ ├─ 954 cat /var/console
           │ ├─1045 /usr/sbin/bash -l
           │ ├─1939 /usr/sbin/bash -l
           │ ├─1949 systemctl status // <- status command and shell is here
           │ └─1950 less
           ├─system.slice
// you get the idea ...

However using machinectl to make systemd start a shell for you works around this issue:

[siryellsalot@test ~]$ for i in {1..400} ; do ( sleep 1024 & ); done
[siryellsalot@test ~]$ systemctl status
● test.gengar
    State: running
    Units: 563 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2024-02-01 22:26:37 UTC; 20min ago
  systemd: 255.3-1-arch
   CGroup: /
           ├─init.scope
           │ ├─   1 /usr/lib/systemd/systemd --system --log-target=console --unit=multi-user.target
           │ ├─ 951 script -c "cat /var/console" /dev/null
           │ ├─ 954 cat /var/console
           │ ├─1045 /usr/sbin/bash -l
           │ ├─1939 /usr/sbin/bash -l
           │ ├─1951 sudo machinectl shell siryellsalot@.host
           │ ├─1952 sudo machinectl shell siryellsalot@.host
           │ ├─1953 machinectl shell siryellsalot@.host
           │ ├─2780 /usr/sbin/bash -l
           │ ├─2790 systemctl status
           │ └─2791 less
           ├─system.slice
           │ ├─dbus-broker.service
           │ │ ├─1050 /usr/bin/dbus-broker-launch --scope system --audit
           │ │ └─1057 dbus-broker --log 4 --controller 9 --machine-id a33d0612fca8459588a9801705f6f80e --max-bytes 53687>
           │ ├─systemd-journald.service
           │ │ └─1019 /usr/lib/systemd/systemd-journald
           │ ├─systemd-logind.service
           │ │ └─1058 /usr/lib/systemd/systemd-logind
           │ └─systemd-machined.service
           │   └─1954 /usr/lib/systemd/systemd-machined
           └─user.slice
             ├─user-1000.slice
             │ ├─session-3.scope
             │ │ ├─1955 /usr/sbin/bash -l <- new shell is here
             │ │ ├─1981 sleep 1024
             │ │ ├─1983 sleep 1024
             │ │ ├─1985 sleep 1024
// sleeping beauty be like: 

This doesn't work to fix the my original use case, which was to use VsCode + Platform IO (that hit the limit) because``machinectl shell``` discards all stuff that distrobox does to integrate with host.
Any ideas?
The workaround also only raises the limit to somewhere around 660 however that should still be enough

@sir-yells-alot sir-yells-alot added the bug Something isn't working label Feb 1, 2024
@89luca89
Copy link
Owner

89luca89 commented Feb 3, 2024

Hi @sir-yells-alot pushed a fix for it now, and seems to work correclty:
Screenshot from 2024-02-03 16-56-24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants