Conversation
|
7da57a5 to
3568674
Compare
|
Issue could be related to dependency to package |
|
It seems that doesn't matter if the |
|
Reproduced on my env. In addition, upgrade from previous version launches with no such error (tested with 18.8.4 -> 18.9.0 local build). Reports of similar errors have been traced to the database being accessed before it was fully initialized or lacks migration. As far as I checked, the database is mostly empty (none of the tables or anything else derived from gitalb were created) after the gitlab container exits. running 18.8.4. The result is 1050 rows. psql -> \dt * on postgresql for 18.8.4 restored from production envnewly created 18.9.0. The result is only 64 rows, all of which are standard data that comes with PostgreSQL. psql -> \dt * postgresql for newly created 18.9.0 |
|
My upgrade from 18.8.4 to 18.9.0 in my dev environment did work. In a new test installation I'm running into the same issue. Another finding - maybe unrelated (from gitlab 18.9.0 release page): I'm rebuilding with ruby 3.3.10 right now. |
|
Database issue still present with ruby 3.3.10. Ruby 3.3 changes: delete assets/build/patches/ruby/0001-avoid-seeding_until-ruby3.3.0.patch |
|
Looking into stack trace, If the behavior of |
|
Well, I checked gitaly log (/var/log/gitlab/supervisor/gitaly.log*) and found that gitaly.socket is on strange path. There might be an update for gitaly config file or something else.
|
|
I see 2 listen statements: time="2026-02-24T11:28:06.050Z" level=info msg="listening at address" address=/home/git/gitlab/tmp/sockets/private/gitaly.socket pid=980 schema=unix |
Yeah I noticed that after I reported. Still not sure which is active (or both?) |
|
puma and sidekiq also show: PG::UndefinedTable: ERROR: relation "application_settings" does not exist 2026-02-24 12:42:25,949 WARN exited: sidekiq (exit status 1; not expected) After that both are running. Is gitlab_setup slower? |
|
Anyway, I think we can temporally move things forward by disabling call of |
I think it's not. gitlab DB just did not set up correctly and everything stuck. puma and sidekiq can't connect to gitlab (or gitaly, gitlab-workhorse or anything else). |
|
18.9.0 launch successfully with patch :
I'm not sure but we may need to revert the change provided by this patch if not # in assets/runtime/functions Line 2219, migrate_database()
if [[ -z ${COUNT} || ${COUNT} -eq 0 ]]; then
echo "Setting up GitLab for firstrun. Please be patient, this could take a while..."
exec_as_git force=yes bundle exec rake gitlab:setup \
${GITLAB_ROOT_PASSWORD:+GITLAB_ROOT_PASSWORD=$GITLAB_ROOT_PASSWORD} \
${GITLAB_ROOT_EMAIL:+GITLAB_ROOT_EMAIL=$GITLAB_ROOT_EMAIL} >/dev/null
+ else
+ echo "Reverting patch lib/gitlab/gitaly_client/circuit_breaker.rb"
+ git apply -R "${GITLAB_BUILD_DIR}/patches/gitlabhq/0005-Disable-enabled-check-on-circuit_breaker.call.patch"
fi |
checking gitaly v18.9.0 but I could find out no critical change (like rename of Also I noticed that Even I commented out the line, gitaly client get response like below: and |
|
Upstream issue (thanks @th-2021) : https://gitlab.com/gitlab-org/gitlab/-/issues/591292 |
|
18.9.1 doesn't solve this. Error still happening. |
|
@kkimurak do you know how gitaly and gitlab:setup interact? I commented out gitaly and get the same error. |
|
@th-2021 Which file / line did you commented out? Rake task If the database is empty (newly created), If succeed, continues to: -> |
|
I changed the autostart to false in the supervisor config.
|

GitLab 18.9 Release (for more details see https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/)