<p>While someone with knowledge about the innards of GitLab may have known what the error pointed to, it took me some time and bisecting my revision history to find the root cause.</p>

<p>I had introduced a Jinja2 conditional like this in the inlined YAML for LDAP servers:</p>

<pre><code>gitlab_rails['ldap_servers'] = YAML.load &lt;&lt;-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
  somekey: somevalue
  {% if some_variable is defined %}
  key: value
  {% endif %}
EOS
</code></pre>

<p>The <code># remember to close this block with 'EOS' below</code> remark isn't the only caveat you have to worry about here. Indentation is too, as I found out.</p>

<p>Provided the condition became true, the about would have evaluated to:</p>

<pre><code>gitlab_rails['ldap_servers'] = YAML.load &lt;&lt;-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
  somekey: somevalue
    key: value
  EOS
</code></pre>

<p>... where the additional indentation tripped up the YAML parser and caused the unspecific error symptoms (and message).</p>

<p>Hope this helps someone else to avoid a lengthy analysis of the cause, if they run into a similar condition.</p>

CC BY-SA 4.0
2020-01-28T21:54:15.813Z
2020-01-31T08:02:27.987Z
2020-01-31T08:02:27.987Z
0xC0000022L
<p>I have been working on deployment of a GitLab container with Ansible.</p>

<p>At one point the whole thing broke with a terribly unspecific error message. After that point the container kept rebooting about once a minute.</p>

<p>The <code>docker logs &lt;container&gt;</code> command gave me the following output:</p>

<pre><code>Thank you for using GitLab Docker Image!
Current version: gitlab-ce=12.7.2-ce.0

Configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
And restart this container to reload settings.
To do it use docker exec:

  docker exec -it gitlab vim /etc/gitlab/gitlab.rb
  docker restart gitlab

For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md

If this container fails to start due to permission problems try to fix it by executing:

  docker exec -it gitlab update-permissions
  docker restart gitlab

Cleaning stale PIDs &amp; sockets
Preparing services...
Starting services...
Configuring GitLab...
/opt/gitlab/embedded/bin/runsvdir-start: line 37: /proc/sys/fs/file-max: Read-only file system
Starting Chef Client, version 14.14.29
resolving cookbooks for run list: ["gitlab"]
Synchronizing Cookbooks:
  - postgresql (0.1.0)
  - registry (0.1.0)
  - mattermost (0.1.0)
  - consul (0.1.0)
  - gitaly (0.1.0)
  - gitlab (0.0.1)
  - letsencrypt (0.1.0)
  - runit (4.3.0)
  - crond (0.1.0)
  - redis (0.1.0)
  - nginx (0.1.0)
  - acme (4.0.0)
  - package (0.1.0)
  - monitoring (0.1.0)
  - praefect (0.1.0)
Installing Cookbook Gems:
Compiling Cookbooks...

================================================================================
Recipe Compile Error in /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb
================================================================================

Psych::SyntaxError
------------------
(&lt;unknown&gt;): did not find expected key while parsing a block mapping at line 2 column 5

Cookbook Trace:
---------------
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `block in from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/config_mash.rb:29:in `auto_vivify'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `block in from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/config_mash.rb:29:in `auto_vivify'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/config.rb:22:in `from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:26:in `from_file'

Relevant File Content:
----------------------
/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:

 98:
 99:    def from_file(_file_path)
100:      # Throw errors for unrecognized top level calls (usually spelling mistakes)
101:      config_strict_mode true
102:      # Turn on node deprecation messages
103:      Gitlab::Deprecations::NodeAttribute.log_deprecations = true
104:      # Allow auto mash creation during from_file call
105&gt;&gt;     Gitlab::ConfigMash.auto_vivify { super }
106:    ensure
107:      config_strict_mode false
108:      Gitlab::Deprecations::NodeAttribute.log_deprecations = false
109:    end
110:
111:    # Enhance set so strict mode errors aren't thrown as long as the setting is witin our defined config
112:    def internal_set(symbol, value)
113:      if configuration.key?(symbol)
114:        configuration[symbol] = value

System Info:
------------
chef_version=14.14.29
platform=ubuntu
platform_version=16.04
ruby=ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]
program_name=/opt/gitlab/embedded/bin/chef-client
executable=/opt/gitlab/embedded/bin/chef-client


Running handlers:
There was an error running gitlab-ctl reconfigure:

(&lt;unknown&gt;): did not find expected key while parsing a block mapping at line 2 column 5

Running handlers complete
Chef Client failed. 0 resources updated in 01 seconds
</code></pre>

<gitlab>
Containerized (official) GitLab CE starts and ends up in a boot loop with LDAP configuration
0xC0000022L
# Containerized (official) GitLab CE starts and ends up in a boot loop with LDAP configuration

(Asked by: username_0 on 2020-01-28)

I have been working on deployment of a GitLab container with Ansible.
At one point the whole thing broke with a terribly unspecific error message. After that point the container kept rebooting about once a minute.
The docker logs  command gave me the following output:
Thank you for using GitLab Docker Image!
Current version: gitlab-ce=12.7.2-ce.0

Configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
And restart this container to reload settings.
To do it use docker exec:

  docker exec -it gitlab vim /etc/gitlab/gitlab.rb
  docker restart gitlab

For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md

If this container fails to start due to permission problems try to fix it by executing:

  docker exec -it gitlab update-permissions
  docker restart gitlab

Cleaning stale PIDs & sockets
Preparing services...
Starting services...
Configuring GitLab...
/opt/gitlab/embedded/bin/runsvdir-start: line 37: /proc/sys/fs/file-max: Read-only file system
Starting Chef Client, version 14.14.29
resolving cookbooks for run list: ["gitlab"]
Synchronizing Cookbooks:
  - postgresql (0.1.0)
  - registry (0.1.0)
  - mattermost (0.1.0)
  - consul (0.1.0)
  - gitaly (0.1.0)
  - gitlab (0.0.1)
  - letsencrypt (0.1.0)
  - runit (4.3.0)
  - crond (0.1.0)
  - redis (0.1.0)
  - nginx (0.1.0)
  - acme (4.0.0)
  - package (0.1.0)
  - monitoring (0.1.0)
  - praefect (0.1.0)
Installing Cookbook Gems:
Compiling Cookbooks...

================================================================================
Recipe Compile Error in /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb
================================================================================

Psych::SyntaxError
------------------
(): did not find expected key while parsing a block mapping at line 2 column 5

Cookbook Trace:
---------------
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `block in from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/config_mash.rb:29:in `auto_vivify'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `block in from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/config_mash.rb:29:in `auto_vivify'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:105:in `from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/config.rb:22:in `from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:26:in `from_file'

Relevant File Content:
----------------------
/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/libraries/helpers/settings_helper.rb:

 98:
 99:    def from_file(_file_path)
100:      # Throw errors for unrecognized top level calls (usually spelling mistakes)
101:      config_strict_mode true
102:      # Turn on node deprecation messages
103:      Gitlab::Deprecations::NodeAttribute.log_deprecations = true
104:      # Allow auto mash creation during from_file call
105>>     Gitlab::ConfigMash.auto_vivify { super }
106:    ensure
107:      config_strict_mode false
108:      Gitlab::Deprecations::NodeAttribute.log_deprecations = false
109:    end
110:
111:    # Enhance set so strict mode errors aren't thrown as long as the setting is witin our defined config
112:    def internal_set(symbol, value)
113:      if configuration.key?(symbol)
114:        configuration[symbol] = value

System Info:
------------
chef_version=14.14.29
platform=ubuntu
platform_version=16.04
ruby=ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]
program_name=/opt/gitlab/embedded/bin/chef-client
executable=/opt/gitlab/embedded/bin/chef-client


Running handlers:
There was an error running gitlab-ctl reconfigure:

(): did not find expected key while parsing a block mapping at line 2 column 5

Running handlers complete
Chef Client failed. 0 resources updated in 01 seconds

**Tags:** gitlab


---

## 1 answers

### Answer by username_0 on 2020-01-28. Score: 1

While someone with knowledge about the innards of GitLab may have known what the error pointed to, it took me some time and bisecting my revision history to find the root cause.
I had introduced a Jinja2 conditional like this in the inlined YAML for LDAP servers:
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
  somekey: somevalue
  {% if some_variable is defined %}
  key: value
  {% endif %}
EOS

The # remember to close this block with 'EOS' below remark isn't the only caveat you have to worry about here. Indentation is too, as I found out.
Provided the condition became true, the about would have evaluated to:
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
  somekey: somevalue
    key: value
  EOS

... where the additional indentation tripped up the YAML parser and caused the unspecific error symptoms (and message).
Hope this helps someone else to avoid a lengthy analysis of the cause, if they run into a similar condition.


---

