Fix Sidekiq crash when gitlab.yml contains UTF-8 characters
What does this MR do and why?
In GitLab 16.0, we migrated away from Settingslogic
in
!113040 (merged) and
started using ActiveSupport::ConfigurationFile.parse
.
However, if GitLab Omnibus were configured with non-ASCII characters, such as German Umlauts, Sidekiq would fail to start up due to:
incompatible character encodings: US-ASCII and UTF-8
This happened because:
- Ruby sets the default encoding based on the
LANG
environment. - When Omnibus GitLab starts Sidekiq,
LANG
is blank. As a result, Ruby'sEncoding.default_external
returnsUS-ASCII
. - When
ActiveSupport::ConfigurationFile.parse
runs, it attempts to scan for certain UTF-8 characters, but this fails in GitLab 16.0 since the file is read asUS-ASCII
. - Just by calling
require 'rails'
, Rails sets the encoding to UTF-8: https://github.com/rails/rails/blob/v6.1.7.2/railties/lib/rails.rb#L21C1-L24 - However,
sidekiq-cluster
doesn't attempt torequire 'rails'
before it attempts to load the settings, and so it will crash if non-ASCII characters are present.
To fix this, set the encodings inside the GitlabSettings::Settings
class to ensure configuration files are parsed as UTF-8.
Note that users can work around the issue by setting LANG
:
gitlab_rails['env'] = {
'LANG' => 'C.UTF-8'
}
Relates to #412767 (closed)
How to set up and validate locally
- In Omnibus GitLab 16.0.1, set
/etc/gitlab/gitlab.rb
:
gitlab_rails['gitlab_email_display_name'] = 'GitLab SambaÉdu'
- Run
gitlab-ctl reconfigure
. - Run
gitlab-ctl tail sidekiq
and watch the errors. - Apply this change in
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab_settings/settings.rb
. - Sidekiq should start.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Stan Hu