Gitlab 14: Removed configurations found in gitlab.rb. Aborting reconfigure

On upgrading to GitLab 14 from 13.12.5, I got the following errors:

Removed configurations found in gitlab.rb. Aborting reconfigure.


Removals:
* unicorn['worker_processes'] has been deprecated since 13.10 and was removed in 14.0. Starting with GitLab 14.0, Unicorn is no longer supported and users must switch to Puma, following https://docs.gitlab.com/ee/administration/operations/puma.html.
* unicorn['socket'] has been deprecated since 13.10 and was removed in 14.0. Starting with GitLab 14.0, Unicorn is no longer supported and users must switch to Puma, following https://docs.gitlab.com/ee/administration/operations/puma.html.

OK, fair enough, I followed the instructions and I commented out those items from /etc/gitlab/gitlab.rb, but the errors persist. I’ve looked everywhere I can think of on the filesystem with grep, and there’s absolutely no mention of unicorn anywhere that isn’t commented out. I still get the above errors. I also made sure Puma was turned on by adding puma['enable'] = true to /etc/gitlab/gitlab.rb.

I can confirm Puma is actually running under GitLab 13 with ps xa | grep puma. Unicorn is not mentioned anywhere when I ps xa | grep unicorn.

What do I need to do to convince GitLab 14 that I really am not using and that Puma is fine? Running gitlab-ctl reconfigure under GitLab 13 still shows the deprecation warnings, despite all my efforts.

Hi,

Can you try below to double-check and make sure there are no uncommented lines relating to unicorn? Here’s mine as an example:

root@gitlab:~# grep -ir "unicorn" /etc/gitlab/gitlab.rb 

###! Time between sampling of unicorn socket metrics, in seconds
# gitlab_rails['monitoring_unicorn_sampler_interval'] = 10
## GitLab Unicorn
##! Tweak unicorn settings.
##! Docs: https://docs.gitlab.com/omnibus/settings/unicorn.html
# unicorn['worker_timeout'] = 60
# unicorn['worker_processes'] = 2
# unicorn['listen'] = '127.0.0.1'
# unicorn['port'] = 8080
# unicorn['socket'] = '/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket'
# unicorn['pidfile'] = '/opt/gitlab/var/unicorn/unicorn.pid'
# unicorn['tcp_nopush'] = true
# unicorn['backlog_socket'] = 1024
# unicorn['somaxconn'] = 1024
# unicorn['log_directory'] = "/var/log/gitlab/unicorn"
###! Docs: https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/
###!       https://github.com/kzk/unicorn-worker-killer
# unicorn['worker_memory_limit_min'] = "400 * 1 << 20"
# unicorn['worker_memory_limit_max'] = "650 * 1 << 20"

my gitlab.rb doesn’t have any puma lines, since by default it will use puma and it’s default settings unless otherwise specified. A similar post was yesterday: Upgrading from 13.12 to 14.0 which you can use for reference as well.

Sure:

# grep -ir "unicorn" /etc/gitlab/gitlab.rb
##! Tweak puma settings. You should only use Unicorn or Puma, not both.
# GitLab Unicorn #
## Tweak unicorn settings.
# unicorn['enable'] = false
# unicorn['worker_timeout'] = 60
# unicorn['off_worker_processes'] = 2
# unicorn['listen'] = '127.0.0.1'
# unicorn['port'] = 8080
# unicorn['off_socket'] = ' /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket'
# unicorn['pidfile'] = '/opt/gitlab/var/unicorn/unicorn.pid'
# unicorn['tcp_nopush'] = true
# unicorn['backlog_socket'] = 1024
# unicorn['somaxconn'] = 1024
# unicorn['log_directory'] = "/var/log/gitlab/unicorn"
## see https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/
## and https://github.com/kzk/unicorn-worker-killer
# unicorn['worker_memory_limit_min'] = "400 * 1 << 20"
# unicorn['worker_memory_limit_max'] = "650 * 1 << 20"

If you were to set:

unicorn['enable'] = false

by uncommenting and then running gitlab-ctl reconfigure does that help bypass the errors? I don’t know of any other place it could be reading settings from, so doesn’t make too much sense.

OK, I found it. In my Kubernetes configuration I was setting the GITLAB_OMNIBUS_CONFIG environment variable and that’s where the settings were coming from. Once I removed the unicorn settings from that environment variable everything started working.

Thanks for the help; sorry for the distraction. Maybe my goof will help someone else!

2 Likes