Any attempt to use gitlab-rails in container just does not work. It looks like it hangs intinitely, but trying to run it with strace shows some intel.
At first i found this error: Gem Load Error is: Could not find a JavaScript runtime. See https://github.com/rails/execjs`` for a list of available runtimes.in `’ ``
I installed JS inside container only to run into this one: Bundler::GemRequireError: There was an error while trying to load the gem 'toogle'. Gem Load Error is: cannot load such file -- toogle
I ran sed -i '/toogle/s/^/#/' Gemfile to turn it off only to run into the next one: Bundler::GemRequireError: There was an error while trying to load the gem 'sigdump/setup'. Gem Load Error is: cannot load such file -- sigdump/setup
At this point i created absolutely new compose and tried clear installment - still does not work.
Any ideas? It definetely does not look like a normal behaviour.
The reported gdk-toogle and sigdump errors concern development/test gems. They are intentionally absent from the production image and excluded through:
BUNDLE_WITHOUT:
- development
- test
Therefore, commenting them out—or installing JavaScript inside the container—is not an appropriate fix. The errors suggest that GitLab’s packaged Bundler configuration was ignored or altered.
I tried usual, intended command multiple time, it just hangs and at some point whole console just stops responding at all, even to something like Ctrl+C.
So, about other commands:
uname -m: x86_64
docker exec gitlab-rails console - no response, hangs forever (just getting a disconnect “client_loop: send disconnect: Connection reset”)
but if i interrupt it early with Ctrl+C i get this: Ruby: ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-linux] GitLab: 18.11.9 (7d3d034bc81) FOSS GitLab Shell: 14.50.0 PostgreSQL: 17.10 ------------------------------------------------------------[ booted in 70.83s ] Loading production environment (Rails 7.2.3.1) Switch to inspect mode.
Ngl, it’s deepseek generated, because at some point i ran out of ideas and tried to use AI to find a solution.
Just in case this info is relevant, docker settings are almost default, the only thing changed is daemon.json: { "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3", "compress": "true" } }
Also i checked Postgre and Redis inside container, they seem to work completely fine.
The output confirms that Rails completes its boot:
[ booted in 70.83s ]
Loading production environment (Rails 7.2.3.1)
The SSH connection reset and the entire console becoming unresponsive point toward host resource pressure rather than a missing gem.
How much RAM and how many vCPUs does the host have? GitLab currently lists 16 GB RAM as the single-node baseline and 8 GB for constrained installations:
Ideally, keep this running in a second SSH session during the test:
docker stats <container>
If SSH disconnects again, check the kernel journal after reconnecting or through the hosting provider’s console.
The generated strace command bypasses the supported gitlab-rails wrapper and invokes a raw Rake environment through su. It also does not set RAILS_ENV=production.
I would disregard the resulting execjs, toogle, and sigdump errors for now. They come from a different execution path.
Please share the command outputs, especially the memory totals and kernel journal. That should tell us whether the kernel killed the Rails or SSH process.
Dynamic docker stats showed mostly stable resource usage, except for CPU %. It fluctuated all the way from 1-5% up to 115%.
Also journalctl has a lot of entries like this (while using docker stats): Aug 14 16:42:41 gitlab-vm containerd[860]: time="2026-08-14T16:42:41.965352143Z" level=error msg="unable to parse "max 0" as a uint from Cgroup file "/sys/fs/cgroup/system.slice/docker-111cb8b96ceed8e585890a3d43e66d3c06bf02da75140cfb221049091413c76a.scope/hugetlb.2MB.events""
Also i ran a bit modified version of your docker exec command and results seem a bit strange to me.
I noticed 1:02.50elapsed wasn’t quite true, since it take like 15 mins to get output message.
I then ran 3 times date +"%T.%N" && sudo docker exec gitlab-docker1-gitlab-1 gitlab-rails runner 'puts :runner_ok' && date +"%T.%N" with these results:
But third time the problem is that it showed 2 min later than it actually executed, which confuses me even more tbh.
And i ran date +"%T.%N" && sudo time docker exec gitlab-docker1-gitlab-1 gitlab-rails runner 'puts :runner_ok' && date +"%T.%N"
result was 16:57:27.763125432 client_loop: send disconnect: Connection reset
with Aug 14 17:14:53 gitlab-vm systemd[1]: session-6.scope: Deactivated successfully. Aug 14 17:14:53 gitlab-vm systemd[1]: session-6.scope: Consumed 3.818s CPU time. Aug 14 17:14:53 gitlab-vm systemd-logind[829]: Session 6 logged out. Waiting for processes to exit. Aug 14 17:14:53 gitlab-vm systemd-logind[829]: Removed session 6.
in journalctl.
?column?
1
(1 row)
real 0m0.148s
user 0m0.003s
sys 0m0.009s
5. time sudo docker exec gitlab-docker1-gitlab-1 \
gitlab-redis-cli ping
PONG
real 0m0.137s user 0m0.002s sys 0m0.010s
And i tried to launch it on host directly and it works just fine.
I’m genuinely confused, why it works that way, ngl.
Completely clear ubuntu 24.04, base gitlab image, usual SSH connection. Nothing out of place as far as i can see. Well, gonna work with console using host then.
If you wish to investigate further, i’ll do what i can to help you, if not - thanks a lot for helping me and your time.
