JESUS! Why in the world is this project so badly bugged?

 

- Updated on monday: Nothing worked. Container did not start up.

- Solution: I had to create a ton of missing directories inside the container that were missing for PGSQL to startup.

 

- Updated today: Container is starting up. ALL CSS Styles are missing and in debug view of the browser I see Error 502

- Solution: None so far. Should I switch back to gitea where the testing is far better and everything works?

- Solution #2: restart gitlab container. Now the styles work...

 

GODDAMMIT! I just wanted a working solution... Seems this is not possible anymore these days.

Edited June 27, 20242 yr by ftrueck

Be honest - has anyone actually gotten SMTP (google) to work with this container?

I've configured the gitlab.rb file as per documentation (the password is an App password as Non-Secure app logins are being deprecated this september)

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.google.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "*******@gmail.com"
gitlab_rails['smtp_password'] = "*************"
gitlab_rails['smtp_domain'] = "smtp.google.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = ******************.org'
gitlab_rails['gitlab_email_display_name'] = 'GitLab'

 

ports 9080, 9443 and 22 are forwarded as per default docker template. I've later added 857, 443 and 80 as well just to be sure.

Either way, the connection always fails with:

irb(main):001:0> Notify.test_email('[email protected]', 'Message Subject', 'Message Body').deliver_now
Delivered mail [email protected] (120122.7ms)
/opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:1214:in `__connect_nonblock': Cannot assign requested address - connect(2) for [2a00:1450:4025:c03::1b]:587 (Errno::EADDRNOTAVAIL)
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:1214:in `connect_nonblock'
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:56:in `connect_internal'
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:137:in `connect'
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:642:in `block in tcp'
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:227:in `each'
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:227:in `foreach'
        from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:632:in `tcp'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:643:in `tcp_socket'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:656:in `do_start'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:611:in `start'
        from /opt/gitlab/embedded/service/gitlab-rails/config/initializers/mail_starttls_patch.rb:53:in `start_smtp_session'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:2145:in `do_delivery'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:253:in `block in deliver'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:588:in `block in deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in `block in instrument'
        ... 20 levels...

 

I am able to receive SMTP emails using the same account from Authelia (without extra port forwardings).

Both Authelia and GitLab are in the same docker network.

Edited July 19, 20241 yr by BentoFox
Add details

Hey Guys,

 

I noticed couple of weeks ago that my cpu is spiking periodically (like every 2 to 3 seconds) which yanks up my total system powerusage up to 80Watts (normally around 30 to 40Watts). Since I was coding on my VM I didnt pay too much attention but when I noticed powerusage was still spiking when noone was around (I can monitor the powerusage using homeassistant).

 

Let me start that this process got upto 15 to 20% (but seen spikes upto 75% cpu usage) every 2 to 3 second and I have no idea why. It never behaved like this and imho it shouldnt.

 

Then i started to shutdown dockers and vm's to see which one is responsible and the minute I stopped the Gitlab-CE the cpu stopped spiking. My Gitlab-CE is just my projects repo - there are no pipelines, ci/cd or webhooks configured.

 

Really would like some help on this

Hi,

I tried now for the third time to install gitlab-ce, but always something went wrong. The app seems to take up a lot of processor resources, since at the moment the web interface of my unraid server is more or less frozen and not reacting. Does this app has high hw requirements? I have a Fujitsu FUTRO S920 Thin Client AMD GX-415GA 64GB Flash 4GB DDR3 and some external terabyte hard disks.

Edited September 1, 20241 yr by DrFlowerkick

9 hours ago, DrFlowerkick said:

Hi,

I tried now for the third time to install gitlab-ce, but always something went wrong. The app seems to take up a lot of processor resources, since at the moment the web interface of my unraid server is more or less frozen and not reacting. Does this app has high hw requirements? I have a Fujitsu FUTRO S920 Thin Client AMD GX-415GA 64GB Flash 4GB DDR3 and some external terabyte hard disks.

I had the same issue and it was basically working on first install, then causing issue everytime the docker is restarted, eating all my ram and causing a server crash. I have 16GB of ram, 8 available.

 

Best advice I can get is to throttle the RAM consumption in the docker setting and enable swap memory.
Also, unistall the docker and reinstall it configured to use little to no memory.

With these configured, I was able to fix my configuration.

And yes, 4GB DDR3 isn't enough really, but I gave it 2GB of RAM and it has access to swap. Works well now.

Edited September 2, 20241 yr by dboris

As of yesterday I got an 500 error on the frontend with these lines from the postgresql log:

2024-09-04_05:23:14.34374 FATAL:  could not resize shared memory segment "/PostgreSQL.1945094446" to 84976 bytes: No space left on device
2024-09-04_05:23:14.34684 LOG:  database system is shut down
2024-09-04_05:23:15.38092 FATAL:  could not resize shared memory segment "/PostgreSQL.2018239940" to 84976 bytes: No space left on device
2024-09-04_05:23:15.38360 LOG:  database system is shut down

 

I need to fix this quite urgent

 

Additional: A lot of these:

{"severity":"WARN","time":"2024-09-04T06:52:35.985Z","message":"writing value to /dev/shm/gitlab/puma/gauge_all_puma_1-0.db failed with unmapped file"}

 

 

Edited September 4, 20241 yr by sjoerd

Eureka! I got it:

 

I still have my backup/secondary unraid server online where gitlab-ce also runs. The automatic backup procedure started to fail 3 days ago. They only thing I changed was the hardware - I did a major, like MAJOR hardware overhaul. Went from an i5-8600k (6cores)/ 16G to a i9--14900 with 64G.

 

I restored the last good backup on my secondary unraid and all was fine, so I concluded (wrongly) that the PostgreSQL database got corrupted somehow.

 

Now that I have a running gitlab-ce docker on the other unraid server I was fine with deleting the image and the content on the volumes (I kept the backups and scripts I made and the ssl certificates), but an entirely new installation of the image/container gave me the same errors. What the heck is going on???

 

When I googled /dev/shm, docker and postgresql I learned that /dev/shm could be full. Logging into the container console the /dev/shm was 64Mb (default size) and entire used where at my other unraid server it was only user for 20Mb - why? The other results from my search brought me on two gitlab pages:

 

- https://docs.gitlab.com/ee/install/docker/troubleshooting.html
- https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5476

 

And there you have it - I added "--shm-size 265m" to the extra parameters. Restarted the container and YEAH. Al i have to do is restore the backup 🙂. When I check the `/dev/shm` I got this now:

 

# df -hP | head -1 && df -hP | grep shm
Filesystem      Size  Used Avail Use% Mounted on
shm             256M   91M  166M  36% /dev/shm

 

 

I also added --memory 16G but that got me a message about kernel not supporting memory limitation although when I check the docker page on advanced I does actually say 14G/16G used for the container..  See this thread

 

 

I too was having an issue, the fix was simple enough the docker container needed a larger SHM originally it was set to 64MB

 

Added the flag "--shm-size=512m" to the end of the "Extra Parameters" that can be seen when "Basic View" is toggled to "Advanced View"

 

Basis for the change can be found here:
https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5476

I've updated to new hardware thats quite beefy, dual xeon platinum, total of 108 cores, 512gig ram. After that I could not start the container, running out of threads or shm memory. Setting shm memory to 2G did not help at all. Solution was to limit the number of puma threads. guess this can be done in the container settings with pinning. Just a heads up when you provide lots of hw to the container

Edited November 7, 20241 yr by Output

I have been running this gitlab-ce container for quite some time, mostly without issue. However, it is now to the point where it does not run, and doesn't even seem to properly (re)install.

 

In recent attempts to update, or to remove and reinstall, the last docker layer (ID ...fdbd) does not say "Pull complete." at the end. See attached file for the output from the installer.

 

It does say it installs, but when I try to start the container, it almost immediately stops. Log is also in the attached file.

 

Any suggestions?

gitlab update log

i have this image running no problem all that is fine however i think this has memory leak with grows over time.
also if you shut down and restart the container i get the following error
 

unning handlers complete
[2025-02-19T12:48:38-08:00] ERROR: Exception handlers complete
Infra Phase failed. 11 resources updated in 24 seconds

Deprecations:
* git_data_dirs has been deprecated since 17.8 and will be removed in 18.0. See https://docs.gitlab.com/omnibus/settings/configuration.html#migrating-from-git_data_dirs for migration instructions.

Update the configuration in your gitlab.rb file or GITLAB_OMNIBUS_CONFIG environment.

Notes:
Default admin account has been configured with following details:
Username: root
Password: You didn't opt-in to print initial root password to STDOUT.
Password stored to /etc/gitlab/initial_root_password. This file will be cleaned up in first reconfigure run after 24 hours.

NOTE: Because these credentials might be present in your log files in plain text, it is highly recommended to reset the password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.

[2025-02-19T12:48:38-08:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2025-02-19T12:48:38-08:00] FATAL: ---------------------------------------------------------------------------------------
[2025-02-19T12:48:38-08:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2025-02-19T12:48:38-08:00] FATAL: ---------------------------------------------------------------------------------------
[2025-02-19T12:48:38-08:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: execute[/opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8] (postgresql::enable line 59) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 ----
STDOUT: The files belonging to this database system will be owned by user "gitlab-psql".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are disabled.
STDERR: initdb: error: directory "/var/opt/gitlab/postgresql/data" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/var/opt/gitlab/postgresql/data" or run initdb
with an argument other than "/var/opt/gitlab/postgresql/data".
---- End output of /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 ----
Ran /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 returned 1

** Press ANY KEY to close this window ** 

 

Can anyone help me out here - my current gitab-ce container crashes after using the frontend (browsing, editting etc). I got a bunch of errors in the log I can't figure out so I decided to create a second instance of the image with an other name, volumes and ports obv. The container is starting and according to the logs the container starts but I'm getting this message:

My unraid server is obv named "pleiades" with ip 10.34.51.55

 

2025-04-27_08:52:05.02666 {"time":"2025-04-27T08:52:05.026635033Z","level":"ERROR","msg":"Failed to get receptive agents","mod_name":"kas2agentk_tunnel","error":"Get \"http://pleiades.local:7080/api/v4/internal/kubernetes/receptive_agents\": read tcp 172.17.0.2:43788->10.34.51.55:7080: read: connection reset by peer"}

 

The container starts with these settings (all settings are from the unraid gui)

 

docker run
  -d
  --name='GitLab-CE-NEW'
  --net='bridge'
  --cpuset-cpus='16,17,18,19,20,21,22,23'
  --pids-limit 2048
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="pleiades"
  -e HOST_CONTAINERNAME="GitLab-CE-NEW"
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://pleiades.local:7080'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/tynor88/docker-templates/master/images/gitlab_small.png'
  -p '7080:9080/tcp'
  -p '7443:9443/tcp'
  -p '7022:22/tcp'
  -v '/mnt/user/appdata/gitlab-ce-new/config':'/etc/gitlab':'rw'
  -v '/mnt/user/appdata/gitlab-ce-new/data':'/var/opt/gitlab':'rw'
  -v '/mnt/user/appdata/gitlab-ce-new/log':'/var/log/gitlab':'rw'
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://pleiades.local:7080'"
  --shm-size 1G
  --memory 16G
  --cpus 8 'gitlab/gitlab-ce'

 

The container should start - the only thing that is different in the setup are the different ports on the HOST side, so why does my browser keep saying "site can't be reached"  - unraid is listening on 7080 so ???. When I do "curl http://pleiades:7080" I get back
"curl: (56) Recv failure: Connection reset by peer" - I don't get it.. And here is comes: when I change  -p '7080:9080/tcp' -p '7443:9443/tcp'  -p '7022:22/tcp' back to -p '9080:9080/tcp' -p '9443:9443/tcp'  -p '9022:22/tcp' the container start and I can loging (i stop the "main" gitlab container ofc otherwise why would have an issue with ports already in use...

 

Anyhow - I dont understand... I should not matter what the host-ports are as long as they are mapped to the container port.

 

I already tried the changing nginx["listen_port"] = 7080 but that is the container-port.. I should not have to temper with that.

 

Anyone know what's going on.. I really need create a second instance so I can move all my repositories to the new instance

 

So i got it working - had the hack the template because somehow the mappings need to be the same so I changed 9080 to 7080 and and had the change the gitlab.rb config for that (nginx['listen_port'] = 7080) but I got no idea what the heck is going on.. I added my own user, added some groups and got tons op redis / sidekiq errors and timeouts.. It used to be very stable stable till last couple of months - say 6 months or something. I'm using the same image as work but on a vm that's configured as a dockerserver, also the latest and we never got issues there - I even got ldap authentication working there...

 

I got the feeling GitLAB-CE really needs a compose file for all the separate services. When I browse and check settings on the admin area the container uses a 8 cores flatout which also makes the entire unraid server somewhat unresponsive. This should not happen.

 

Even stopping the container from the gui results in an error - I got logged of from the unraid server and need to relog to the gui.. That on its own is already a weird behaviour.

 

As much as I love gitlab - this is not funny anymore.

 

Anyone else having issues like this?"

 

Oke,

 

I created a rhel9 based vm with 8G and 4 cores, installed the docker-engine on it and fired-up a GitLab-CE container with a compose file and it runs butter smooth. The /var/lib/docker is mounted on a btrfs partition but should not be necessary, as docker uses its own overlay these days. I suspect something is not configured entirely correct on the docker-engine on the unraid server itself but there is really not much to configure from the UI itself..  Why do I think that: I fresh install of GitLab-CE on unraids docker crashes over and over (yes, I deleted the entire appdata/gitabce directory)

All this started after I upgraded to unraid 7 - not implying unraid 7 is the issue but it might - Other dockers (plex, mariadb, netdata, wordpress, krusader, phpmyadmin (by default disabled)) are still working fine.

So I spent all day yesterday trying to configure the container, at the end i did it my way.

I write the procedure here for future reference and to hopefully help other people.

• Install the container, leave it as is.

• In an Unraid terminal edit gitlab config:

sudo docker exec -it GitLab-CE editor /etc/gitlab/gitlab.rb

this opens a "vim style" editor. This means to edit the file you need to press 'i', then edit the file. To exit from edit mode you press 'ESC'.

So press 'i' and uncomment (take out the '#' symbol from the beginning of the line) and edit the following lines:

external_url 'https://your.domain.com'
gitlab_rails['trusted_proxies'] = ['172.18.0.0/16','your_unraid_ip','your.domain.com']
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "0.0.0.0:9080"                                                                                                  
gitlab_workhorse['auth_backend'] = "http://localhost:8080"
puma['listen'] = '0.0.0.0'                                                      
puma['port'] = 8080

change 'your.domain.com' and 'your_unraid_ip' accordingly. You will also need to change the ip range '172.18.0.0/16', this must be in the same range of your nginx/swag container, it could be '172.16.0.0/15' or '172.15.0.0/18' for you, you must check it in your Unraid GUI.

After that press 'ESC' to exit edit mode and type ':wq' + enter , this saves the file and exits the editor.

• Rebuild config and restart

  type the following commands in Unraid terminal:

  sudo docker exec -it GitLab-CE gitlab-ctl reconfigure
  sudo docker exec -it GitLab-CE gitlab-ctl restart

  At this point gitlab is configured and ready to run

• Nginx config

  this is the config, replace 'your.domain.com' and 'unraid_ip' accordingly:

  server {
    listen *:80;
    server_name  your.domain.com;
    server_tokens off; ## Don't show the nginx version number, a security best practice
    return 301 https://$http_host$request_uri;
  }
  
  server {
    # If a different port is specified in https://gitlab.com/gitlab-org/gitlab-foss/blob/8-8-stable/config/gitlab.yml.example#L182,
    # it should be declared here as well
    listen *:443 ssl;
    server_name  your.domain.com;
    server_tokens off; ## Don't show the nginx version number, a security best practice
  
    client_max_body_size 1G;
    chunked_transfer_encoding on;
  
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_prefer_server_ciphers off;
  
  
    location / {
      proxy_set_header  Host              $http_host;
      proxy_set_header  X-Real-IP         $remote_addr;
      proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_set_header  X-Forwarded-Proto $scheme;
      proxy_set_header  X-Forwarded-Ssl   "on";
      proxy_set_header  X-Frame-Options   SAMEORIGIN;
      proxy_pass        http://*unraid_ip*:9080;
    }
  }

  With all of this, my instance is working perfectly. I'm using it in a relatively simple and basic way, that means cloning, commiting, pulling, pushing...

  For more advanced things you probably will need to mess with the config a bit.

Edited October 29, 2025Oct 29 by server_lice_007

I just had a quick question regarding this docker instance of GitLab-CE:

After first starting the docker for the first time I noticed that it started spamming the local docker logs and took up > 20GB of memory within the first hour using the default configuration. Everything is working great now after disabling the puma workers in the /etc/gitlab/gitlab.rb file as follows:

puma['min_threads'] = 0

puma['max_threads'] = 0

Unfortuantely, I am still having a problem when this docker auto-updates as it stomps on the local /etc/gitlab/gitlab.rb changes.. which then effectively kills my unraid server within a few hours (128GB!!). I'm assuming some of you have experienced this? I was hoping that someone has figured out a way for future updates to avoid stomping on local /etc/gitlab/gitlab.rb changes.

Thanks!!

Memory Container Issues and Crashes and Mysterious postgreSQL hangs

This container template has been setup without any memory constraint. By default, the GitLab CE Docker container on Unraid has no memory limit — it can consume all available host RAM. On a shared Unraid server running multiple containers, this creates a dangerous condition known as memory overcommit.

You could see this using the following docker command: [my docker container is gitlab-ce]

docker exec gitlab-ce cat /proc/meminfo | grep Committed_AS
Committed_AS:   41168020 kB

if Committed_AS exceeds your total physical RAM and you have no swap, the kernel has no safety net. When that committed memory is actually accessed, the **OOM (Out of Memory) killer** fires — silently terminating processes without warning.

In my case over the last several weeks i've been chasing the following issues:

1. OOM killer terminates a PostgreSQL background worker

2. PostgreSQL freezes — process stays alive but stops accepting connections

3. Puma (Rails app server) can no longer reach the database and hangs

4. Workhorse socket goes stale

5. nginx returns 502 Bad Gateway on all pages

The deceptive part: gitlab-ctl status shows all services as running. The broken state is not obvious without digging into logs.

Emergency fix (when already broken) [Your docker may not be named 'gitlab-ce']

docker exec gitlab-ce gitlab-ctl restart postgresql

docker exec gitlab-ce gitlab-ctl restart puma

Set a Hard Memory Limit

### Choosing a limit

Check your current container memory usage first:

```bash

docker stats --no-stream gitlab-ce

```

For my personal GitLab instance with default Omnibus settings, 6GB seems like a reasonable starting point.

Option 1: Unraid Docker UI

1. Go to Docker tab in Unraid web UI

2. Click the GitLab container icon → Edit

3. Scroll to Extra Parameters

4. Add --memory=6g to the existing parameters

5. Click Apply — Unraid will recreate the container with the limit

Or

On Unraid host

vi /boot/config/plugins/dockerMan/templates-user/my-gitlab-ce.xml

```

Find the <ExtraParams> line and add --memory=6g to it:

<ExtraParams>... --memory=6g --shm-size 265m ...</ExtraParams>

Verify: [use your docker container name]

docker stats --no-stream --format 'Memory: {{.MemUsage}}' gitlab-ce

Memory: 3.998GiB / 6GiB

Running in a Memory-Contrained Environment

I will edit this post with enhancements as I discover recommended settings from https://docs.gitlab.com/omnibus/settings/memory_constrained_envs/

In my environment, I have configured a 6GB container memory limit.

I am currently experimenting with the following settings:

postgresql['shared_buffers'] = '1536MB'
postgresql['log_min_duration_statement'] = 1000 # log queries > 1 second
puma['worker_processes'] = 0
puma['worker_processes'] = 2
puma['min_threads'] = 1
puma['max_threads'] = 4
sidekiq['concurrency'] = 10
gitlab_rails['gitlab_signup_enabled'] = false
gitlab_rails['usage_ping_enabled'] = false
gitlab_rails['service_ping_enabled'] = false
gitlab_kas['enable'] = false # GitLab Agent Server — not needed without Kubernetes
registry['enable'] = false # Container registry
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
node_exporter['enable'] = false
postgres_exporter['enable'] = false
prometheus['enable'] = false
prometheus_monitoring['enable'] = false
puma['exporter_enabled'] = false
redis_exporter['enable'] = false
sidekiq['metrics_enabled'] = false

## jemalloc faster memory release
gitlab_rails['env'] = {
'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

## Gitaly env (combine with existing gitaly['env'] if present)
gitaly['env'] = {
'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000',
'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}

Long Reboot Recovery

As a separate issue --- the stop timeout on the container is only 10s. If Unraid reboots, the postgreSQL only has 10s to complete its shutdown before docker sends a 'SIGKILL'

LOG: database system was not properly shut down; automatic recovery in progress

Use the same technique as above

Option 1: Unraid Docker UI

1. Go to Docker tab in Unraid web UI

2. Click the GitLab container icon → Edit

3. Scroll to Extra Parameters

4. Add --stop-timeout=120 --restart=unless-stopped to the existing parameters

5. Click Apply — Unraid will recreate the container with the limit

vi /boot/config/plugins/dockerMan/templates-user/my-gitlab-ce.xml

Add --stop-timeout=120 to Extra Parameters in the Unraid template alongside the

memory limit:

```xml

<ExtraParams>... --memory=6g --stop-timeout=120 --restart=unless-stopped ...</ExtraParams>

```

After applying changes or recreating the container, verify settings persisted:

```bash

# Restart policy

docker inspect gitlab-ce | grep -A2 RestartPolicy

            "RestartPolicy": {

                "Name": "unless-stopped",

                "MaximumRetryCount": 0

# Stop timeout

docker inspect gitlab-ce | grep StopTimeout

            "StopTimeout": 120

Extra Parameters

These are the extra parameters that i currently have set. Remove references the in the --env section if you do not need them

Note: The environment is all one statement surrounded by double-quotes for GITLAB_ONIBUS_CONFIG

--env GITLAB_OMNIBUS_CONFIG="external_url 'external_url https://gitlab.domain.net; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;"

My ExtraParams

<ExtraParams>--log-opt max-size=10m --log-opt max-file=1 --env GITLAB_OMNIBUS_CONFIG="external_url 'external_url https://gitlab.domain.net; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;" --add-host=gitlab.domain.net:x.x.x.x --memory=6g --shm-size 265m --pids-limit 2048 --stop-timeout=120 --restart=unless-stopped </ExtraParams>

Puma Crashes

Update: Switched Puma to single mode (worker_processes = 0)

After investigating a recurring issue where gitlab-ctl status showed puma as "running" despite the socket refusing connections,

Trying to switch to single mode (worker_processes = 0)

# /etc/gitlab/gitlab.rb
puma['worker_processes'] = 0
puma['min_threads'] = 1
puma['max_threads'] = 4

Edited March 22Mar 22 by codyrat

I don't know what I'm doing wrong, but I'm trying to get this thing online and the system won't initialize. These are the errors in the logs on first boot.

{"severity":"WARN","time":"2026-03-16T22:31:11.064Z","meta.caller_id":"Ci::UnlockPipelinesInQueueWorker","correlation_id":"8c22fd5e13898263d8219674f8db8e23","meta.root_caller_id":"Cronjob","meta.feature_category":"job_artifacts","meta.client_id":"ip/","message":"writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with read/write operation attempted while mmap was being written to"}

{"severity":"WARN","time":"2026-03-16T22:31:11.064Z","meta.caller_id":"Ci::UnlockPipelinesInQueueWorker","correlation_id":"8c22fd5e13898263d8219674f8db8e23","meta.root_caller_id":"Cronjob","meta.feature_category":"job_artifacts","meta.client_id":"ip/","message":"writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with read/write operation attempted while mmap was being written to"}

docker run
  -d
  --name='GitLab-CE'
  --net='br0.3'
  --ip='10.10.3.99'
  --pids-limit 2048
  -e TZ="America/Los_Angeles"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Unraid2"
  -e HOST_CONTAINERNAME="GitLab-CE"
  -e 'TCP_PORT_9080'='9080'
  -e 'TCP_PORT_9443'='9443'
  -e 'TCP_PORT_22'='9022'
  -e 'GITLAB_OMNIBUS_CONFIG'='gitlab_rails['\''enable_puma_sampler'\''] = false; gitlab_rails['\''enable_sidekiq_sampler'\''] = false'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:9080]'
  -l net.unraid.docker.icon=''
  -v '/mnt/cache/appdata/gitlab-ce/config':'/etc/gitlab':'rw'
  -v '/mnt/cache/appdata/gitlab-ce/data':'/var/opt/gitlab':'rw'
  -v '/mnt/cache/appdata/gitlab-ce/log':'/var/log/gitlab':'rw'
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://unraid:9080/'"
  --memory=12g 'gitlab/gitlab-ce'

I recently tried to update to the latest version of gitlab from 18.10.7. The update migrates to a Postgresql database v17. The upgrade fails and I am stuck on the second to most recent version. Please advise.