Mark_LAN Posted April 19, 2023 Share Posted April 19, 2023 (edited) @Germanus4711 Quote I guess the odd way is actually the "default" config file, which the author has provided with 'some or more' options described in a text block marked by 2 x '#', denoting that that is an actual comment following. A style that has been around since the 80s. Having only 1 x '#' stands for an optional, not by default enabled option, again, old school. New to me but I only have a light software and random IT background where //is a comment /*so is this*/ and everything else is not. "defaults" being one way and actual comments another is interesting but it does make sense. First time really noticing something done that way, even if it is old school, thanks for the lesson. Quote As for the "workers", that is an architectural part of the software in question. The developers decided to "thread-out" specific parts of the "application", mostly for performance reasons and sometimes due to coding styles. When one disables a worker thread, the functionality becomes either not available or, gets migrated over to something called a "green thread" or, falls back to some hard-coded code block, e.g. just throwing an exception. In the documentation I linked, they stated that performance was the goal. Just not needed for me, a single user environment. Quote The statement "'0' for min also lets the system scale", made me think for a second where the scaling might come from. In the case that 0 disables the option, as outlined, it will not exist and scales nicely as it does nothing no matter how much it scales. 0 for 'worker_processes' disables the multiple executables running the function, but not the function. Docs linked it stays active and is recommend in low ram environments. # for 'min_threads' was defaulting 2 PER WORKER at 800MB of RAM a piece. Supposedly now that I put the min to any number below the max it will actually scale down, for any number of 'worker_processes' BUUUT what matters is I did the recommended changes (removed the '#'s) and re-ran "sudo gitlab-ctl reconfigure" I have reduced about 3GB of ram consumption from over 5GB to just under 2GB for the gitlab-ce docker and maybe 1% or so less of the constant low level CPU chatter gitlab-ce seems to make. That would be a huge difference on a tiny system and was a nice learning experience for me, thanks again for the insight. Edited April 19, 2023 by Mark_LAN grammar Quote Link to comment
Xenor Posted May 9, 2023 Share Posted May 9, 2023 Quote New to me but I only have a light software and random IT background where //is a comment /*so is this*/ and everything else is not. "defaults" being one way and actual comments another is interesting but it does make sense. First time really noticing something done that way, even if it is old school, thanks for the lesson. Comments you mentioned are used in many languages but not Ruby https://www.tutorialspoint.com/ruby/ruby_comments.htm, and Ruby is what's used to build GitLab :). Quote Link to comment
wm-te Posted May 27, 2023 Share Posted May 27, 2023 (edited) I've just reinstalled gitlab-ce container. I've got correct SMTP info in the config, but I'm not seeing signs that its sending emails. I'm using mailgun - which is working well for unraid notifications, and other containers I'm running. Mailgun logs show no emails hitting their server. I'd like to troubleshoot it - but need a few pointers. Where should I check in the container to see what is happening when it tries to send an email? Gitlab-ce log files show this message ==> /var/log/gitlab/sidekiq/current <== sh: 1: /usr/sbin/sendmail: not found If I enter the container and edit /etc/gitlab/gitlab.rb with the correct info, I receive emails ok. So it looks like the problem is SMTP config settings not being picked up when the container is started. Edited May 28, 2023 by wm-te added more log info, and a workaround. Quote Link to comment
Vitor Ventura Posted June 5, 2023 Share Posted June 5, 2023 Hello there. I'm facing some problems. I have configured GitLab-CE behind reverse proxy (NPM), but when go to issues redirect to external URL configured in Extra Parameters. I had changed external_url to my domain (git.domain.com), but after that i can't access GitLab-CE. Issue work with external url NGPM Config Any help, appreciate. Quote Link to comment
Romcik077 Posted July 18, 2023 Share Posted July 18, 2023 On 6/5/2023 at 5:14 PM, Vitor Ventura said: Hello there. I'm facing some problems. I have configured GitLab-CE behind reverse proxy (NPM), but when go to issues redirect to external URL configured in Extra Parameters. I had changed external_url to my domain (git.domain.com), but after that i can't access GitLab-CE. Issue work with external url NGPM Config Any help, appreciate. Hello, I solved this issue. I used next configuration https://ben.goodacre.name/tech/Setup_Gitlab_behind_off-loaded-slash-reverse_proxy_SSL_(such_as_AWS_ALB), just instead of port 80 use 9080 as it is used in docker. NginxProxyManager confgiuration should not be changed. BR, Roman! 1 Quote Link to comment
Vitor Ventura Posted August 29, 2023 Share Posted August 29, 2023 On 7/18/2023 at 5:18 AM, Romcik077 said: Hello, I solved this issue. I used next configuration https://ben.goodacre.name/tech/Setup_Gitlab_behind_off-loaded-slash-reverse_proxy_SSL_(such_as_AWS_ALB), just instead of port 80 use 9080 as it is used in docker. NginxProxyManager confgiuration should not be changed. BR, Roman! I've managed, and its working now. Thanks 1 Quote Link to comment
kuhnino Posted September 22, 2023 Share Posted September 22, 2023 (edited) Sorry Gents, I have spend now hours of reading docus and forums etc, But I'm unable to get the "random" root password, nor can I login as admin to my GitLab-CE instance. Maybe already bit confused of so much rake and sudo commands, so that I do not get to the point anymore, feeling a bit lost Any ide/help is much apreciated Edited September 22, 2023 by kuhnino typo errors Quote Link to comment
TheBrian Posted October 19, 2023 Share Posted October 19, 2023 On 9/21/2023 at 11:55 PM, kuhnino said: Sorry Gents, I have spend now hours of reading docus and forums etc, But I'm unable to get the "random" root password, nor can I login as admin to my GitLab-CE instance. Maybe already bit confused of so much rake and sudo commands, so that I do not get to the point anymore, feeling a bit lost Any ide/help is much apreciated I found my temporary root password at "/mnt/cache/appdata/<my container data dir>/config/initial_root_password" Quote Link to comment
ulemon Posted December 27, 2023 Share Posted December 27, 2023 (edited) So I removed my gitlab-ce docker and I am having issues reinstalling it, I keep getting this error, I have done a fair bit of searching but I don't fully understand it. I think some sort of clean removal would help? i thought I did that with the app cleaner plugin but it did not fix the issue Quote IMAGE ID [896269304]: Pulling from gitlab/gitlab-ce. IMAGE ID [3dd181f9be59]: Already exists. IMAGE ID [5222e10cb5b3]: Already exists. IMAGE ID [b86fffbd1d96]: Already exists. IMAGE ID [a8f85f865bd2]: Already exists. IMAGE ID [fd086081fce9]: Already exists. IMAGE ID [9c3df03dc259]: Already exists. IMAGE ID [539bd3fbd6f5]: Pulling fs layer. Downloading 100% of 5 KB. Download complete. Extracting. IMAGE ID [fceb275916b3]: Pulling fs layer. Downloading 100% of 1 GB. Verifying Checksum. Download complete. TOTAL DATA PULLED: 1 GB Error: failed to register layer: stat /var/lib/docker/btrfs/subvolumes/409c120c078213d51556454112f17e2e71e52a6c070fc59f6927ffd991bf11f2: no such file or directory UPDATE: fixed my own problem by following the steps from this thread: Quote Corrupt docker.img. Delete and recreate https://wiki.unraid.net/Manual/Docker_Management#Re-Create_the_Docker_image_file Reinstall containers as Previous Apps https://wiki.unraid.net/Manual/Docker_Management#Re-Installing_Docker_Applications Edited December 27, 2023 by ulemon Quote Link to comment
CJW Posted December 27, 2023 Share Posted December 27, 2023 I used to have GitLab-CE running fine. Then the big update that changed the storage backend broke things. I spent a while fiddling with that but eventually decided to say screw it and start fresh. All my repos are copied to github, as well, so I didn't lose any data. So, starting with a completely fresh install of the GitLab-CE docker v16.7.0, things seemed to work. Got it installed, got root set up, added a regular user, had the user add a blank repo and an SSH key that I validated with a simple ssh command to connect. I just can't push or clone anything. Every attempt to interact with the GitLab instance fails with "remote: Internal API unreachable" on the command line. I don't know jack about how this software works. It's too complicated. But poking around in the logs I see things that make no sense on a clean install that shows no health issues in the Monitoring tab. The following line shows up multiple times whenever I do a push/clone operation: [puma/puma_stderr.log] 2023-12-27 23:17:46 +0000 Rack app ("GET /api/v4/internal/allowed" - (127.0.0.1)): #<ThreadError: deadlock; recursive locking> Error reached top of thread-pool: stack level too deep (SystemStackError) Anybody got any ideas? I've about had it with the "improvements" to this container. Something that used to "just work" has now become an aggravating time suck. Thanks. Quote Link to comment
CJW Posted December 28, 2023 Share Posted December 28, 2023 Just for an extra bit of fun, the debugging output in gitlab-rails/application_json.log grew to 250G overnight and maxed my cache drive. Quote Link to comment
ulemon Posted December 29, 2023 Share Posted December 29, 2023 On 12/27/2023 at 5:26 PM, CJW said: I used to have GitLab-CE running fine. Then the big update that changed the storage backend broke things. I spent a while fiddling with that but eventually decided to say screw it and start fresh. All my repos are copied to github, as well, so I didn't lose any data. So, starting with a completely fresh install of the GitLab-CE docker v16.7.0, things seemed to work. Got it installed, got root set up, added a regular user, had the user add a blank repo and an SSH key that I validated with a simple ssh command to connect. I just can't push or clone anything. Every attempt to interact with the GitLab instance fails with "remote: Internal API unreachable" on the command line. I don't know jack about how this software works. It's too complicated. But poking around in the logs I see things that make no sense on a clean install that shows no health issues in the Monitoring tab. The following line shows up multiple times whenever I do a push/clone operation: [puma/puma_stderr.log] 2023-12-27 23:17:46 +0000 Rack app ("GET /api/v4/internal/allowed" - (127.0.0.1)): #<ThreadError: deadlock; recursive locking> Error reached top of thread-pool: stack level too deep (SystemStackError) Anybody got any ideas? I've about had it with the "improvements" to this container. Something that used to "just work" has now become an aggravating time suck. Thanks. maybe resetting docker like i did in the post above would help? not sure... Quote Link to comment
Argus9 Posted January 9 Share Posted January 9 I can't interact with my GitLab repos over SSH. I've generated an ed25519 key pair and added the public key to my Profile > SSH Keys section. However, I'm trying to push a branch to a repo I created, but when trying to push I'm asked to enter the password for `[email protected]` (mydomain.com is a fake name here). I can push/pull over HTTPS just fine, but I'd rather use SSH for ease and security. I'm also a GitHub user and I don't have this problem with repos I try to access over GitHub. It seems like the problem is isolated to this GitLab instance. What should I do to try and debug this? Quote Link to comment
dboris Posted February 17 Share Posted February 17 (edited) Hello I tried installing and removing entirely the docker multiple times without having any success. Basically I can't manage to access the GUI. I managed to crash my server as ram usage goes off the roof. I tried limiting the ram : still doesn't work. Edit : I checked the docker folder's permission and it was all messed up. I created the gitlab-ce folder myself and reinstalled it. Edit : The template was installing it on my media / HDD folder, for an unknown reason, when my app data should only be on my SSD drive. Edit it works this morning, but I cry : 7.44GB/used. CPU usage on the docker being displayed "0.46%". Overall CPU load is >90% and when I shut down the docker, load I goes back to 5-20%. On 11/11/2018 at 6:05 PM, Squid said: You can always limit the memory usage https://forums.unraid.net/topic/57181-real-docker-faq/?page=2#comment-566088 Doesn't work for me, zero repos as well. Repports errors and GUI doesn't work if allocated with 4GB of memory, which should be it's minimum requirement for 500 users. Edited February 19 by dboris Quote Link to comment
Amachamax Posted Monday at 11:47 PM Share Posted Monday at 11:47 PM Your docker can have a port issue preventing it from starting and doesn't have the option to change the port easily. I removed the time of the log, but here is the issue in the log: caller=main.go:932 level=error msg="Unable to start web listener" err="listen tcp 127.0.0.1:9090: bind: address already in use" Will you add an option to change this 9090 port in the docker options to prevent this issue? 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.