Unable to start more than docker containers (Ubuntu vServer) - linux

Question

I am currently desperately looking for help. I am trying to get my server up and running using docker containers but it seems I have hit a wall.
I have rented a vServer (4 Cores, 8 GB RAM) and I am trying to get everything up and running.
A brief overview of my idea:
Traefik as reverse proxy to distribute my applications
Crowdsec for security and traefik middleware
As Applications: Gitea, Nextcloud and a basic Apache/PHP Web-Server
Watchtower managing updates
I installed everything using docker compose images, and it works but has one major flaw:
I am unable to start every container.
At first, I thought everything worked until I realised that the last container I started, forced another container to exit with Code 137.
To avoid that I added resource limits to my docker-compose.yml files:
deploy:
resources:
limits:
cpus: '0.001'
memory: 50M
reservations:
cpus: '0.0001'
memory: 20M
I populated the values as I seemed fit for each container. After that, no container was shut down again, but now I am unable to get the last container up (It's not any specific container, just the last container I try to start.).
I get one of the following three error messages:
$ docker compose up -d
[+] Running 3/4
⠿ Network nextcloud_default Created 3.5s
⠿ Container nextcloud-redis Started 1.3s
⠿ Container nextcloud-db Starting 2.1s
⠿ Container nextcloud-app Created 0.2s
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 2, stdout: , stderr: runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
goroutine 0 [idle]:
runtime: unknown pc 0x7f6605cd0a7c
stack: frame={sp:0x7ffd4137b1a0, fp:0x0} stack=[0x7ffd40b7c810,0x7ffd4137b850)
0x00007ffd4137b0a0: 0x000055de6cee2154 <runtime.funcspdelta+0x0000000000000034> ...
$ docker compose up -d
...
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: failed to write "380000": write /sys/fs/cgroup/cpu,cpuacct/docker/dfbfa79b7a987b1248a5498fbd6fe4438a68cb0e147a3285a8638a845193f4bf/cpu.cfs_quota_us: invalid argument: unknown
Or with sudo:
$ sudo docker compose up -d
...
Error response from daemon: failed to create shim task: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v2.task/moby/dfbfa79b7a987b1248a5498fbd6fe4438a68cb0e147a3285a8638a845193f4bf/log.json: no such file or directory): runc did not terminate successfully: exit status 2: unknown
I did absolutely nothing in between these commands, and I got different error messages. Huh?
I think it might be some resource issue, but inspecting the server with htop or my containers with docker stats shows the absolute opposite. CPU idles at 1-5% and 800M of 8GB RAM are used.
After some research I found this but my understanding of the linux OS is not that deep, that I can certainly say this has something to do with my issue. Furthermore, I don't get how I would set systemd.unified_cgroup_hierarchy=0.
I tried to increase vm.min_free_kbytes and took a look at
$ ulimit
unlimited
and obviously searched the internet. But sadly, I didn't find any exact matching issues. (Or I didn't use the correct buzzwords as my understanding of Linux is not that deep.)
Any idea would be much apprecheated!
Thanks!
P.S.: Here are some version details of my server:
$ docker --version
Docker version 20.10.23, build 7155243
$ uname -r
5.2.0
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) CPU E5-2680 v3 # 2.50GHz
CPU family: 6
Model: 63
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 2
BogoMIPS: 4994.44
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nons
top_tsc aperfmperf eagerfpu cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm abm epb invpcid_single intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pt
s md_clear spec_ctrl intel_stibp flush_l1d
Virtualization features:
Virtualization: VT-x
Hypervisor vendor: Parallels
Virtualization type: container
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 30 MiB (1 instance)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy

Answer 1

Ok I have found the issue.
My hosting provider has a process limit on their VMs. I asked them to increase it, and now my issue is gone.