ScratchCat Posted July 31, 2021 Share Posted July 31, 2021 On 7/30/2021 at 1:36 AM, MrSqueak said: Hello, On June 22, 2021 Gitlab updated from major version 13 to 14. When starting the docker the logs say that I need to update to the newest major version and then it shuts down the image. I could possibly manually update within the image but I cannot get the image to stay up past logging that I need to update. I would appreciate any suggestions that could get me through this as this is my only source control that I am currently using. Thanks! Hello. You need downgrade your version on 13.9.2. Then you need upgrade gitlab version step by step 13.9.2 -> 13.12.6 -> 14.0.5 -> 14.1.0 -> latest Quote Link to comment
andre4k14 Posted August 14, 2021 Share Posted August 14, 2021 How can I downgrade the docker container ? I tried the command in the terminal: docker pull gitlab/gitlab-ce:13.9.2-ce.0 On 7/31/2021 at 10:09 AM, ScratchCat said: Hello. You need downgrade your version on 13.9.2. Then you need upgrade gitlab version step by step 13.9.2 -> 13.12.6 -> 14.0.5 -> 14.1.0 -> latest Quote Link to comment
frakman1 Posted August 15, 2021 Share Posted August 15, 2021 (edited) 3 hours ago, andre4k14 said: How can I downgrade the docker container ? I tried the command in the terminal: docker pull gitlab/gitlab-ce:13.9.2-ce.0 On 7/31/2021 at 4:09 AM, ScratchCat said: You do that by editing the docker template page. Goto the DOCKER tab, click on Gitlab-CE and select "Edit" Locate the field labeled Repository. It should be set to gitlab/gitlab-ce:latest This is what controls what version of Gitlab-CE you are using. A quick breakdown of the components of this string is: gitlab: user on dockerhub gitlab-ce: name of the repository latest: version To change it to something else, first find out what the official tags are from the dockerhub page for that project here. Click on the Tags tab and search for the version that you want. For example, 13.9.2, would correspond to 13.9.2-ce.0 Now enter that version instead of latest in the Repository field of the Gitlab-CE docker template: Repository: gitlab/gitlab-ce:13.9.2-ce.0 Hope that helps! Edited August 15, 2021 by frakman1 1 Quote Link to comment
andre4k14 Posted August 15, 2021 Share Posted August 15, 2021 Thank you, you made my day. May the Force be with you 1 Quote Link to comment
Adrian Posted August 26, 2021 Share Posted August 26, 2021 So what's the default username/password to use for a new install? And where exactly is that documented, just curious to see why I had trouble finding it. Quote Link to comment
tjb_altf4 Posted August 28, 2021 Share Posted August 28, 2021 On 8/26/2021 at 11:50 AM, Adrian said: So what's the default username/password to use for a new install? And where exactly is that documented, just curious to see why I had trouble finding it. Had a similar issue, I fixed it this way... Run this command in the gitlab docker CLI (not unraid CLI): gitlab-rake "gitlab:password:reset[root]" This will start the password reset process for root. Quote Link to comment
polandar Posted September 3, 2021 Share Posted September 3, 2021 After testing, I try to explore gitlab deploy for my cloudways php apps and after generating the SSH Key, uploading them and deploying the app, I got the stuff I need and it's indeed one interesting platform to surf. Thanks for the headsup and for opening the tab. Highly appreciated! Quote Link to comment
Adrian Posted September 5, 2021 Share Posted September 5, 2021 On 8/28/2021 at 7:13 AM, tjb_altf4 said: Had a similar issue, I fixed it this way... Run this command in the gitlab docker CLI (not unraid CLI): gitlab-rake "gitlab:password:reset[root]" This will start the password reset process for root. Just got back in town, thank you! this worked. Quote Link to comment
firetime Posted October 6, 2021 Share Posted October 6, 2021 (edited) Leaving this here for anyone else who may have similar issues: After moving the appdata folder (due to changing cache drive setup) and copying data across, my GitLab-CE was crashing unraid server randomly. On my previous hardware it would hard lock up and become 100% unresponsive. My new hardware would detect the hard lock and auto restart the server causing a parity recheck due to unclean shutdown. By the end it was crashing the server in less than 5 minutes of the docker container active. The fix was to start the container and execute the below command from the unraid terminal: sudo docker exec GitLab-CE update-permissions Container is working fine without crashing. Additionally the issue was likely caused by a recursive permissions command run in the wrong folder. Because of this running New Perms or Docker Safe New Perms from the tools page before the above command is a good idea. Edited October 6, 2021 by firetime 1 Quote Link to comment
Marshalleq Posted October 7, 2021 Share Posted October 7, 2021 I wonder if that will work for my Nextcloud docker. Hmmm Quote Link to comment
AinzOolGown Posted December 5, 2021 Share Posted December 5, 2021 (edited) Hi Guys ! After the latest update, my GitLab-ce won't boot anymore 😭 It launch, take it's time like always and progressively take memory, but never it is accessible again by the WebUI/DNS It respond to ping but that's all... Please, help ! I'm developping a website+app for my own brand new company and all the projects are on it 😱 I'll gladly share any more log you'll need, but it seems to have a lot, just tell me the one that can help please 😇 Attached is a copy/paste of the log windows in unraid GUI. Thank you very much ! P.S. : If it's more convenient to redo a docker and import the DB (is it even possible ? My projects are not totally lost ?), no problem ^^ GitLab-ce logs.txt Edit SOLVED : Back online again ! Phew~~ 😌 That was a problem with external_url param. With some little changes and a downgrade/upgrade, all working again, thanks nonetheless Edited December 5, 2021 by AinzOolGown Solved Quote Link to comment
alexciurea Posted December 5, 2021 Share Posted December 5, 2021 Hi @AinzOolGown In my case I faced a problem with my gitlab-ce docker installation during updates because: 1) no autoapdates, and 2) I did not follow the update path recommended by gitlab. When I manually updated, it jumped from a very old version to latest. The container was not starting because db was failing; I think the db upgrade scrips failed. So I manually updated step by step, using specifically the respective tags in the docker, based on this info below: https://docs.gitlab.com/ee/update/#upgrade-paths This resolved the issue. Maybe this is already common knowledge for many, but I hope it helps someone failing like me... -a Quote Link to comment
KrisMin Posted December 5, 2021 Share Posted December 5, 2021 (edited) Fresh install. Somehow I cant access the webui on the https port. The default http port works fine. Bug or something with my setup, i cant figure out. Edited December 5, 2021 by KrisMin Quote Link to comment
xer01ne Posted December 7, 2021 Share Posted December 7, 2021 I am using this Gitlab with Hotio's Caddy2 (for serving) and ddclient (for ddns). I have many other projects that work fine, but for some reason, Gitlab will not accept the external_url. I change the external_url to 'https://git.SITE.COM' and run gitlab-ctl reconfigure. When I try to go to the external site, I get a blank page. If I comment it out, everything appears to work fine until I start using Gitlab... I will get 500 errors anytime I try to import a project and when I go to clone projects, The address is localhost instead of SITE.COM. I am obviously improperly configuring Gitlab, but I am not sure what I am doing wrong. Any assistance would be greatly appreciated. - Caddy2 Config - git.SITE.COM { reverse_proxy 192.168.1.7:9080 encode gzip log { output file /config/log/git-SITE.log } } I've left all Gitlab configs default. Quote Link to comment
frakman1 Posted December 7, 2021 Share Posted December 7, 2021 I had a similar problem with localhost URL instead of my actual server when I clone. In the docker template page in Unraid, I had to add the external_url parameter to Extra Parameters and set it to my Gitlab WebUI IP:PORT. In your case, you may want to change it to your actual site URL. --log-opt max-size=10m --log-opt max-file=1 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://MY-UNRAID-IP:9080/'; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;" I use NginxProxyManager to manage the internet-facing URL. Quote Link to comment
xer01ne Posted December 7, 2021 Share Posted December 7, 2021 (edited) frakman1, Edit: That didn't work.... I added two variables on the configure page; "log-opt" with a value of max-size=10m and "env" with a value of GITLAB_OMNIBUS_CONFIG="external_url 'https://git.MYSITE.COM/'; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;" So, question... should I use the IP address of my unraid server or the actual url I am expecting to work? and do I include the https if I am using the url? Didn't seem to respond to that. I am still getting 500 errors on imports and other weird things. Of note, the gitlab.rb didn't seem to change either. Edit 2: Another thing I noticed is the logs are going wild. I get about 40 lines every 3 to 4 seconds. Mostly puma, sidekiq and gitaly. It's going so fast that I can't even see if my requests are hitting the logs. (but it doesn't appear to be) Edited December 7, 2021 by xer01ne Quote Link to comment
frakman1 Posted December 8, 2021 Share Posted December 8, 2021 (edited) Unfortunately, I'm not sure I can help with your specific setup as I have it configured very differently. I use Cloudflare for my DNS and Let's Encrypt for the SSL certificate management within NginxProxyManager. You may need to map my logic to your specific setup. After some trial and error, I was able to get the external URL to work with SSL and have the Clone button in my repo point to the external URL instead of the local IP address: Browser Location bar: Gitlab Clone panel: How come you are setting env variables manually? I put them all as one string under Extra Parameters: I changed external_url to https://mysite.com/ I then made the following changes to gitlab.rb: external_url 'https://mysite.com' nginx['listen_port'] = 9080 nginx['listen_https'] = false and ran gitlab-ctl reconfigure In Nginx Proxy Manager: With the appropriate SSL certificate details for Let's Encrypt The problem I now have is that I am unable to do a git clone on either https or ssh without getting some authentication/SSL error. It used to work when I used the local server's IP address before I changed it to external URL. Edited December 8, 2021 by frakman1 Quote Link to comment
xer01ne Posted December 10, 2021 Share Posted December 10, 2021 Works perfect! I am now using NginxProxyManager and on the Details tab of the domain, I didn't check any of the options (cache assets, block common exploits, etc) and the clone works perfectly! Thank you very much for sharing! 1 Quote Link to comment
Spanky55 Posted December 20, 2021 Share Posted December 20, 2021 On 8/25/2020 at 4:10 PM, andr0id said: Hello I have a problem with my gitlab container. After starting it, it's running great. After round about one day, I only get a " 502 Whoops, GitLab is taking too much time to respond." message. If I look into my logs, it seams that the Redis database it not available anymore. I can restart the container, but after one day it's the same again. What is going wrong? My container settings: Extra Parameters: --env GITLAB_OMNIBUS_CONFIG="external_url 'https://myurl.com/'; gitlab_rails['lfs_enabled'] = true;" Network Type: Custom network with a LetsEncrypt Container Ports HTTP: 5090 HTTPS:5443 Application Data Storage Path: /mnt/user/git/git files/ <-- Share with Cache enabled (Use cache: yes) Config Storage Path and Config Storage Path: Default Path (/mnt/cache/appdata/gitlab-ce) Custom Path: - Container Path: /var/opt/gitlab/gitlab-rails/shared/lfs-objects - Host Path: /mnt/user/git/git lfs files/ <-- Share with Cache enabled (Use cache: yes) gitlab.rb Changes: To prevent the integrated nginx from trying to reach letsEncrypt and communicating with my letsEncrypt container via http instead. nginx[‘listen_port’] = 9080; nginx[‘listen_https’] = false; The GitLab Container Log: ==> /var/log/gitlab/sidekiq/current <== {"severity":"ERROR","time":"2020-08-25T19:40:21.824Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:22.825Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:23.443Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:23.443Z","message":"/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/redis-4.1.3/lib/redis/client.rb:362:in `rescue in establish_connection'"} {"severity":"WARN","time":"2020-08-25T19:40:23.444Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0} {"severity":"ERROR","time":"2020-08-25T19:40:23.445Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"WARN","time":"2020-08-25T19:40:23.445Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0} {"severity":"ERROR","time":"2020-08-25T19:40:23.826Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:24.828Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} ==> /var/log/gitlab/redis-exporter/current <== 2020-08-25_19:40:24.88917 time="2020-08-25T19:40:24Z" level=error msg="Couldn't connect to redis instance" ==> /var/log/gitlab/sidekiq/current <== {"severity":"ERROR","time":"2020-08-25T19:40:25.014Z","message":"heartbeat: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:26.468Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"WARN","time":"2020-08-25T19:40:26.469Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0} {"severity":"ERROR","time":"2020-08-25T19:40:26.470Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"WARN","time":"2020-08-25T19:40:26.470Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0} {"severity":"ERROR","time":"2020-08-25T19:40:26.830Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:27.831Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:28.446Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"ERROR","time":"2020-08-25T19:40:28.447Z","message":"/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/redis-4.1.3/lib/redis/client.rb:362:in `rescue in establish_connection'"} {"severity":"WARN","time":"2020-08-25T19:40:28.447Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0} {"severity":"ERROR","time":"2020-08-25T19:40:28.448Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} {"severity":"WARN","time":"2020-08-25T19:40:28.449Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0} ==> /var/log/gitlab/puma/puma_stdout.log <== {"timestamp":"2020-08-25T19:40:28.795Z","pid":322,"message":"PumaWorkerKiller: Consuming 3111.04296875 mb with master and 4 workers."} ==> /var/log/gitlab/sidekiq/current <== {"severity":"ERROR","time":"2020-08-25T19:40:28.832Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"} I was getting this error as well. I also had qBittorrent running. I ended up moving it off of port 8080 on to another port (8888). This did involve having to add a custom port and removing the previously allocated one for 8080. Apparently the reason is that the internal container also needs to be on the same port (8888). So if you just update the existing parameter to 8888, the internal port is still 8080 and you won't be able to connect to it. So just create a new port parameter and set both of them to be 8888 (or whatever you want the new port to be) and then erase the old 8080 port mapping (for me it was Host Port 3). Then I restarted GitLab and it's been running stable since (it's been about 4 days so far) Quote Link to comment
francknoahk Posted January 21, 2022 Share Posted January 21, 2022 On 8/28/2021 at 5:13 AM, tjb_altf4 said: Had a similar issue, I fixed it this way... Run this command in the gitlab docker CLI (not unraid CLI): gitlab-rake "gitlab:password:reset[root]" This will start the password reset process for root. I am new to docker / unraid so sorry if this seems trivial. How does one access the gitlab docker CLI? Quote Link to comment
frakman1 Posted January 21, 2022 Share Posted January 21, 2022 6 minutes ago, francknoahk said: How does one access the gitlab docker CLI? You right click on the GitLab-CE entry in the Docker tab of the UnRaid webpage, then select Console Hope that helps! 1 Quote Link to comment
live4soccer7 Posted February 6, 2022 Share Posted February 6, 2022 Is it normal for this docker to create entries in the log every few seconds or so? I just worry about the log size and if there is a possible issue causing this. Quote Link to comment
coreylane Posted February 11, 2022 Share Posted February 11, 2022 On 2/5/2022 at 7:35 PM, live4soccer7 said: Is it normal for this docker to create entries in the log every few seconds or so? I just worry about the log size and if there is a possible issue causing this. Gitlab is s a complex and busy app for sure, mine is constantly writing logs as well. How long has your Gitlab instance been running, a week? Check out how much space the log files are using in /mnt/cache/appdata/gitlab-ce/log - Are they being rotated? Quote Link to comment
live4soccer7 Posted February 11, 2022 Share Posted February 11, 2022 I just turned it off for now since I'm not using it at the moment. I do plan to soon, so I will check on this. Thank you Quote Link to comment
frakman1 Posted February 11, 2022 Share Posted February 11, 2022 On 2/5/2022 at 8:35 PM, live4soccer7 said: Is it normal for this docker to create entries in the log every few seconds or so? I just worry about the log size and if there is a possible issue causing this. You can limit log file sizes by changing the environment variable in your Edit docker template page. Mine looks like this. I disabled prometheus because it's a giant hog. --log-opt max-size=10m --log-opt max-file=1 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://MY-UNRAID-IP:9080/'; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;" 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.