3 ms·
"6. Production filesystem IS NOT mounted at this point 9. gitlab-ctl start starts the GitLab with the staging data in /var/opt/gitlab on the root filesystem th
by sciurus 12y ago
"6. Production filesystem IS NOT mounted at this point
9. gitlab-ctl start starts the GitLab with the staging data in /var/opt/gitlab on the root filesystem that doesn’t have any production data. At this point logs report that the production db doesn’t exist which is correct because we are not on the production file system. No production data has been touched at this point. The Gitlab web UI is not responding (502 error from nginx)"
This is what strikes me as needing addressing. There shouldn't be staging data that is normally hidden by mounting the production filesystem. If the production database isn't there, Postgres should fail to start. The Postgres team is pretty adamant that otherwise bad things can happen; see http://www.postgresql.org/message-id/12168.1312921709@sss.pgh.pa.us http://www.postgresql.org/message-id/12168.1312921709@sss.pg...
- sytse 12y agoWe fixed part of the root issue by restarting GitLab automatically when we configure a server as master, preventing it from continuing with the staging data. The staging data was created automatically by gitlab-ctl. I agree that this is confusing and created the item: "Why did GitLab start when it shouldn't?" in the postmortem. Thanks for raising this point.