Ошибка 500 github - Решение и исправление самых разных ошибок на TopOshibok.ru

Right, I believe we are on the same wavelength. I used the link you provided, hit Edit, made my edit and selected “Create a new branch”. After hitting Commit Changes, it takes me to the error page.

Ok, so this time you did manage to create a new branch, but only committing changes failed?

This error 500 page you’re getting is a rather generic error, so it doesn’t really say much about what’s going on. I’ve checked the GitHub Status page and it doesn’t report any services being down right now:

https://www.githubstatus.com/

So the problem is not related to server problems. At this point, I suspect that something is not working properly on the client side, i.e. a problem with your browser or Internet connection.

I use the GitHub WebUI a lot, but not for Git operations though — I do all repository editing locally via Git, and only use the WebUI for pull requests, Issues, etc.

If the problem is due to internet connection failures, or some browser problems, etc., you end up needing to refresh the page (as mentioned in the error page), which puts you at risk of loosing your contents changes.

My advise would be to do one operation at the time, when working in the browser — i.e. first create the branch, then edit the file and commit changes, and then create a pull request. Being in control of each step is better if these errors are frequent.

Also, I suggest you do all editing work in an actual editor, and only when the changed file is ready you then click on Edit, paste your changed contents over the originals (select all and paste over), so that the operation doesn’t take too long — the problem might be related to timeout. At least, if you get the 500 error page, you don’t loose your changes, which are still in the editor.

I also strongly advice against navigating back in history during these delicate operations, since cookies play an important role in account related operations, and using the “back/forward” buttons in the browser is not the same as navigating naturally through GH WebUI, for they might revert some page-related status which GH needs to track your current user session. Also, having multiple GH pages at once might lead to problems, especially if more than on browser tab points at the same page.

Источник

I am unable to clone a newly created repository. I am getting below error.

$ git clone https://github.xxxxx.com/zzzzzz.git
Cloning into 'zzzzzz'...
Username for 'https://github.xxxxxx.com': yyyyy
Password for 'https://yyyyy@github.xxxxxx.com':
remote: Internal Server Error.
remote:
fatal: unable to access 'https://github.xxxxxx.com/zzzzz.git/': The requested URL returned error: 500

I have successfully generated ssh keys and updated the key in github settings as per the instructions in the below URL

https://help.github.com/articles/generating-ssh-keys/

authentication was success when I executed the command:
git -T git@github.xxx.com

Also as per my understanding if we setup the ssh the git clone command should not ask for username and password. But it still asking for them.

debug1: Authentication succeeded (publickey).
Authenticated to github.xxxxx.com ([10.28.22.44]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Hi xxxx! You've successfully authenticated, but GitHub does not provide shell access. 
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3880, received 1696 bytes, in 0.2 seconds
Bytes per second: sent 19132.2, received 8363.0
debug1: Exit status 1

asked Oct 12, 2015 at 16:39

Rob WilkinsonRob Wilkinson

1,1315 gold badges18 silver badges35 bronze badges

This is most probably a problem with GitHub service. I recommend contacting them and explain what the problem is.

This is how Wikipedia explains the 500 response code:

500 Internal Server Error

A generic error message, given when an unexpected condition was
encountered and no more specific message is suitable.

Basically, something went wrong on the GitHub endpoint.

But, since you already have set your SSH keys, you can use the ssh url to clone your repository:

git clone git@github.com:owner/repo.git

answered Oct 13, 2015 at 12:05

Ionică BizăuIonică Bizău

109k89 gold badges290 silver badges476 bronze badges

I have the same problem, but in GitLab, and the answer to the problem is that GitLabis make a deploy.

Deploy in progress
Please try again in a few minutes.

Please contact your GitLab administrator if this problem persists.

So I was connected in a some hours and it is works.

Muhammad Reda

26.4k14 gold badges93 silver badges105 bronze badges

answered May 1, 2017 at 8:02

try with connecting to VPN (at least try with 2 different locations) this worked for me. I was having the same problem

answered Sep 5, 2021 at 3:37

Источник

When attempting to clone a Git repository, you may encounter a 500 error. This error typically occurs when the Git server you are trying to clone from encounters an internal server error. This error can be caused by a number of issues, including network connectivity issues, firewall restrictions, incorrect repository URL, insufficient permissions, and more. Regardless of the root cause, there are a few methods you can use to resolve this error and successfully clone your Git repository.

Method 1: Check Network Connectivity

One possible reason for getting a 500 error on git clone is a network connectivity issue. To fix this, you can check your network connectivity using the following steps:

Ping the server to check if it is reachable.

Check if the port is open and accessible using telnet.

telnet server_address port

Check if the DNS is resolving the correct IP address.

Check if the firewall is blocking the connection.

If the firewall is blocking the connection, you can allow the port using the following command:

sudo ufw allow port_number

By following these steps, you can identify and fix the network connectivity issue causing the 500 error on git clone.

Method 2: Verify Repository URL

To fix the «500 error on git clone» issue with the «Verify Repository URL» method, follow these steps:

Open your terminal or command prompt and navigate to the directory where you want to clone the repository.
Run the following command to verify the repository URL:
```
git ls-remote <repository-url>
```
Replace <repository-url> with the actual URL of the repository.

This command will check if the repository exists and if you have the necessary permissions to access it.
If the above command returns an error, double-check the repository URL and make sure it is correct.
If the repository URL is correct, check if you have the necessary permissions to access the repository. Contact the repository owner or administrator to request access if necessary.
If you have the necessary permissions, try cloning the repository again using the verified repository URL:
```
git clone <verified-repository-url>
```
Replace <verified-repository-url> with the actual verified URL of the repository.

This command should now successfully clone the repository to your local machine.

Example:

$ cd ~/projects
$ git ls-remote https://github.com/username/repo.git
<commit-hash> HEAD
<commit-hash> refs/heads/branch-name
...
$ git clone https://github.com/username/repo.git
Cloning into 'repo'...
remote: Enumerating objects: 123, done.
remote: Counting objects: 100% (123/123), done.
remote: Compressing objects: 100% (87/87), done.
remote: Total 123 (delta 45), reused 110 (delta 32), pack-reused 0
Receiving objects: 100% (123/123), 1.23 MiB | 2.38 MiB/s, done.
Resolving deltas: 100% (45/45), done.

In summary, to fix the «500 error on git clone» issue with the «Verify Repository URL» method, you need to verify the repository URL using the git ls-remote command, check your permissions, and then clone the repository again using the verified URL.

Method 3: Check Firewall Configuration

If you are facing a 500 error while cloning a Git repository, it could be due to a firewall issue. In this case, you need to check your firewall configuration to allow Git traffic.

Step 1: Check Firewall Settings

First, check if your firewall is blocking Git traffic. You can do this by running the following command in your terminal:

If the firewall is active, you should see a message like this:

Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
22/tcp                     ALLOW       Anywhere

If Git traffic is not allowed, you need to add a rule to allow Git traffic.

Step 2: Add Firewall Rule

To add a firewall rule, run the following command:

This will allow Git traffic through the firewall.

Step 3: Verify Firewall Rule

To verify that the Git traffic is allowed, run the following command:

You should see a message like this:

Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
22/tcp                     ALLOW       Anywhere
git                        ALLOW       Anywhere

Step 4: Retry Git Clone

Now, retry the Git clone command. It should work without any errors.

$ git clone <repository-url>

That’s it! You have successfully fixed the 500 error on Git clone by checking the firewall configuration.

Method 4: Try Cloning Over HTTPS

One way to fix the «500 error on git clone» issue is to try cloning over HTTPS. Here are the steps to do so:

Open your terminal or Git bash and navigate to the directory where you want to clone the repository.
Run the following command to clone the repository over HTTPS:
```
git clone https://github.com/username/repo.git
```
Replace «username» with the actual username of the repository owner and «repo» with the name of the repository.
If you are prompted for credentials, enter your GitHub username and password.

If the clone is successful, you should see a message similar to this:

Cloning into 'repo'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (75/75), done.
remote: Total 100 (delta 25), reused 93 (delta 18), pack-reused 0
Receiving objects: 100% (100/100), 5.98 KiB | 1.99 MiB/s, done.
Resolving deltas: 100% (25/25), done.

This means that the repository has been successfully cloned over HTTPS.

Here is an example of cloning a repository over HTTPS:

$ git clone https://github.com/johndoe/my-repo.git
Cloning into 'my-repo'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (75/75), done.
remote: Total 100 (delta 25), reused 93 (delta 18), pack-reused 0
Receiving objects: 100% (100/100), 5.98 KiB | 1.99 MiB/s, done.
Resolving deltas: 100% (25/25), done.

In summary, if you are experiencing a «500 error on git clone» issue, try cloning over HTTPS using the git clone https://github.com/username/repo.git command. This should resolve the issue and allow you to clone the repository successfully.

Method 5: Verify Git Version Compatibility

To fix the «500 error on git clone» issue, you can try verifying the Git version compatibility. Here are the steps to do so:

Check your Git version by running the following command in your terminal:
Verify the Git version compatibility with the server by checking the server’s Git version. You can do this by running the following command:
```
ssh <username>@<server> git --version
```
If the Git versions are not compatible, you can either upgrade your Git version or ask the server administrator to downgrade their Git version.
To upgrade your Git version, you can follow these steps:

a. Install Homebrew by running the following command in your terminal:
```
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```
b. Install Git using Homebrew by running the following command:
Once you have upgraded your Git version, try cloning the repository again using the following command:
```
git clone <repository-url>
```

If the issue persists, you may need to try other solutions such as checking your SSH key or contacting the server administrator.

Источник

The GitHub push internal server error obliterates your programming experience when GitHub experiences a service degradation or outage. As a result, your program halts further procedures and confirms the error: rpc failed; http 500 curl 22 the requested URL returned error: 500 code exception.

Luckily, we searched and discovered the best debugging approaches for this internal server error that will not affect other GitHub statuses or procedures, keeping your project safe.

In addition, we will exemplify the code alterations you must make to your code to pinpoint the cause for the internal server error GitHub with real-life scripts and syntaxes.

Contents

Why Is the GitHub Push Internal Server Error Happening?
- – Pushing Changes for Review in GitHub
- – Experiencing the Error When Starting Several Processes
How to Repair the GitHub Push Internal Server Error in a Few Steps?
- – Replacing the Files and Folders
Conclusion

Why Is the GitHub Push Internal Server Error Happening?

The GitLab push 500 internal server error happens and affects your project or application when GitHub experiences a service degradation or outages. As a result, the system does not render the Git push and pull commands, although most elements, inputs, and values are fully functional.

In other words, the Git remote rejected internal server error almost always happens on GitHub’s behalf, which does not mean no solutions exist. For instance, exceeding the pushed functions in your document launches a server error because GitHub has a limited number of refs you can push from your project simultaneously.

Furthermore, although most elements and inputs in the script are functional, the program will only accept a specific number to avoid the HTTP error 500. However, some syntaxes force these changes and code alterations, causing the application to fail and display an annoying code exception confirming the inconsistencies.

In addition, Git remote failed to report status when running Gitea on-Premise with several repositories and commands. Unfortunately, the program throws an internal server exception confirming the inconsistencies and flaws leading to the broken script and functions.

As a result, we will teach you how to recreate the warning using standard elements and functions before listing the most sophisticated solutions and debugging approaches. Still, you must remember that all projects are unique and use different procedures, but the error’s root remains identical.

– Pushing Changes for Review in GitHub

The former chapter confirmed this bug happens when pushing more changes for review in GitHub than the system can render. Thus, we will exemplify the basic syntax launching the exception and the complete error log. The stack trace should help you identify the culprit.

The following example provides the pushing changes script:

F:\mediawiki\extensions\MobileFrontend>git co –amend

[T210630 334db050e] [WIP] VE: New loading screen design

Date: Thu Jan 13 15:28:59 2022 +0100

6 files changed, 267 insertions(+), 4 deletions(-)

create mode 152696 resources/mobile.editor/init.less

F:\mediawiki\extensions\MobileFrontend>git review -fy

remote:

remote: Processing changes: new: 1 (\)

remote: Processing changes: new: 1 (|)

remote: Processing changes: new: 1 (/)

remote: Processing changes: new: 1 (-)

remote: Processing changes: new: 1 (\)

remote: Processing changes: new: 1 (|)

remote: Processing changes: new: 1, done

remote:

remote: New Changes:

remote: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/486408 [WIP] VE: New loading screen design

remote:

To ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend.git

* [new branch] HEAD -> refs/for/master%topic = T215826

Switched to branch ‘master’

Deleted branch ‘T215826’

Unfortunately, this script malfunctions and displays a mistake. Still, you can use the following example to learn about the bug before applying the changes:

[2022-01-13 16:30:32, 157] [Index-Interactive-7] ERROR com.google.gerrit.index.Schema : error getting field added of ChangeData {46774}

com.google.gwtorm.server.OrmException: Unable to load change 46774

at com.google.gerrit.server.query.change.ChangeData.reloadChange(ChangeData.java:570)

at com.google.gerrit.server.query.change.ChangeData.change(ChangeData.java:557)

at com.google.gerrit.server.query.change.ChangeData.getDiffSummary(ChangeData.java:491)

at com.google.gerrit.server.query.change.ChangeData.computeChangedLines(ChangeData.java:514)

at com.google.gerrit.server.query.change.ChangeData.changedLines(ChangeData.java:526)

at com.google.gerrit.server.index.change.ChangeField.lambda$static$23(ChangeField.java:463)

at com.google.gerrit.index.FieldDef.get(FieldDef.java:138)

at com.google.gerrit.index.Schema$1.apply(Schema.java:185)

at com.google.gerrit.index.Schema$1.apply(Schema.java:180)

at com.google.common.collect.Iterators$6.transform(Iterators.java:788)

at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47)

at com.google.common.collect.Iterators$5.computeNext(Iterators.java:638)

at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)

at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)

at com.google.gerrit.lucene.AbstractLuceneIndex.toDocument(AbstractLuceneIndex.java:289)

at com.google.gerrit.lucene.LuceneChangeIndex.replace(LuceneChangeIndex.java:207)

at com.google.gerrit.lucene.LuceneChangeIndex.replace(LuceneChangeIndex.java:102)

at com.google.gerrit.server.index.change.ChangeIndexer.index(ChangeIndexer.java:207)

at com.google.gerrit.server.index.change.ChangeIndexer$IndexTask.callImpl(ChangeIndexer.java:409)

at com.google.gerrit.server.index.change.ChangeIndexer$IndexTask.callImpl(ChangeIndexer.java:401)

at com.google.gerrit.server.index.change.ChangeIndexer$AbstractIndexTask.call(ChangeIndexer.java:386)

This script completes the first chapter recreating the error and confusing your program. However, other instances that break your application exist.

– Experiencing the Error When Starting Several Processes

We confirmed this inconsistency when starting several processes in your GitHub project or application. As a result, the system displays an exception halting further procedures and code alterations. We will show you the GitAly and web service errors because they indicate failed processes.

You can learn more about the GitAly message below:

{“command.count”:1, “command.inblock”:0 ,”command.majflt”:0, “command.maxrss”:46852, “command.minflt”:142, “command.oublock”:0, “command.real_time_ms”:33, “command.system_time_ms”:2, “command.user_time_ms”:0, “correlation_id”:”01FB98M3DJDGQWG7KBA79Y2NW2″, “grpc.code”:”OK”, “grpc.meta.auth_version”:”v2″, “grpc.meta.client_name”:”gitlab-web”, “grpc.meta.deadline_type”:”regular”, “grpc.method”:”HasLocalBranches”, “grpc.request.deadline”:”2021-07-23T08:45:09.990Z”, “grpc.request.fullMethod”:”/gitaly.RepositoryService/HasLocalBranches”, “grpc.request.glProjectPath”:”jicki/gin”, OK”, “peer.address”:”10.244.23.26:47312″, “pid”:9,”remote_ip”:”10.244.23.145″, “span.kind”:”server”, “system”:”grpc”, “time”:”2021-07-23T08:45:00.813Z”, “username”:”jicki”}

{“correlation_id”:”01FB98M3DJDGQWG7KBA79Y2NW2″, “error”:”rpc error: code = NotFound desc = not found: .gitattributes”, “grpc.code”:”NotFound”, “grpc.meta.auth_version”:”v2″, “grpc.meta.client_name”:”gitlab-web”, “grpc.meta.deadline_type”:”regular”, “grpc.method”:”TreeEntry”, “grpc.request.deadline”:”2021-07-23T08:45:30.035Z”, “grpc.request.fullMethod”:”/gitaly.CommitService/TreeEntry”, “grpc.request.glProjectPath”:”jicki/gin”, NotFound”, “peer.address”:”10.244.23.26:47312″, “pid”:9, “remote_ip”:”10.244.23.145″, “span.kind”:”server”, “system”:”grpc” ,”time”:”2021-07-23T08:45:00.853Z”, “username”:”jicki”}

As you can tell, this example indicates the failed procedures confusing your system. However, the example is only complete after learning about the webservice error:

*** /var/log/gitlab/production.log ***

Started POST “/api/ v4/ projects/ jicki%2Fgin/ repository/commits” for 10.244.23.145 at 2021-07-23 09:06:57 +0000

Processing by Gitlab:: RequestForgeryProtection:: Controller #index as HTML

Completed 200 OK in 3ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 241)

Processing by Gitlab:: RequestForgeryProtection:: Controller #index as HTML

Completed 200 OK in 0ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 107)

GRPC:: NotFound (5:not found: .gitattributes. debug_error_string :{“created”: “@1627031217.322504522”, “description”: “Error received from peer ipv4:10.244.20.6:8075”, “file”:”src/ core/ lib/ surface/ call.cc”, “file_line”:1055, “grpc_message”:”not found: .gitattributes”, “grpc_status”:5}):

/srv/gitlab/vendor/bundle/ruby/2.7.0/gems/grpc-1.30.2-x86_64-linux/src/ruby/lib/grpc/generic/active_call.rb:29:in `check_status’

/srv/gitlab/vendor/bundle/ruby/2.7.0/gems/grpc-1.30.2-x86_64-linux/src/ruby/lib/grpc/generic/active_call.rb:180:in `attach_status_results_and_complete_call’

/srv/gitlab/vendor/bundle/ruby/2.7.0/gems/grpc-1.30.2-x86_64-linux/src/ruby/lib/grpc/generic/active_call.rb:169:in `receive_and_check_status’

/srv/gitlab/vendor/bundle/ruby/2.7.0/gems/grpc-1.30.2-x86_64-linux/src/ruby/lib/grpc/generic/active_call.rb:337:in `each_remote_read_then_finish’

puma: cluster worker 0: 11 [gitlab-puma-worker]:in `each’

Although we could include other inputs and properties, we kept the example short to help you comprehend the exact cause. Still, although the error has many forms and warnings, the debugging methods work for all scripts, so it would help if you remained calm.

How to Repair the GitHub Push Internal Server Error in a Few Steps?

You can repair this dynamic GitHub internal code exception by making modifications to the Git status script and pushing the changes. Consequently, the program will be able to render the inputs without affecting other commands. You can also fix the program by replacing the files and folders.

As you can conclude, repairing your document requires locating the Git status script before changing the inputs. This syntax includes the changes that are not meant for commit, helping you identify the unsuccessful Git pushes, as shown in the following example:

git status

On branch master

Your branch is up to date with the ‘origin/master’.

Changes not staged for commit:

(use “git add <file>…” to update what will be committed)

(use “git restore <file>…” to discard changes in working directory)

modified: test.py

no changes added to the commit (use “git add” and/or “git commit -a”)

After ensuring the branches are up-to-date and running the correct commits, you can push the changes. Please use the following code lines to complete this procedure:

git add test.py

git commit -m “updating test.py”

git push -u origin master

As a result, this script displays an output confirming the procedure is fully functional. You can learn more about the visual output in the following example:

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Delta compression using up to 8 threads

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done.

Total 3 (delta 2), reused 0 (delta 0), pack-reused 0

remote: Resolving deltas: 100% (2/2), completed with 2 local objects.

Everything up-to-date

Your project should no longer experience this annoying code exception.

– Replacing the Files and Folders

You can avoid this mistake by replacing the files and folders from the advanced security window. This solution works for all documents, as explained in the following list:

Right-click your main or Gitea folder.
Navigate to Properties > Security tab > Advanced.
Click on Change on the owner line.
Type your username, select Check Names or add a new name in the Advanced button.
Select OK to return to the Advanced Security window.
Click the check box on the replace sub-container owner and objects.
Click OK to save the changes.

Although this change seems insignificant, it debugs your program and allows further operations.

Conclusion

The GitHub push internal server error obliterates your programming experience when GitHub experiences a service degradation or outage. Luckily, we explained the debugging methods, so let’s revise the details:

The mistake can appear, although most elements and values are fully functional
We recreated the code exception by pushing several changes for review
The debugging procedure requires making small modifications to the Git status script
You can overcome the error by replacing the folders and files

Although developing advanced projects and applications are sometimes challenging, this guide solves one of the most typical errors. Lastly, following these instructions allows your document to render the inputs without affecting other elements.

Author
Recent Posts

Your Go-To Resource for Learn & Build: CSS,JavaScript,HTML,PHP,C++ and MYSQL. Meet The Team

Источник

EDIT: It also happens with pulls.

Summary

Just upgraded to 12.2 and getting random 500 errors when using git and pulling/pushing to a project using HTTPS.

Steps to reproduce

Try to pull any repository using HTTPS on http://lab.shelter.moe (self-hosted gitlab) or push to one you created there.

What is the current bug behavior?

Git commands fail with a 500 error. These errors are random as, when you try pushing again, and again, it sometimes fails during the push, and sometimes the push succeeds.

See this terminal log for an example :

$ git push -u origin master
fatal: unable to access 'https://lab.shelter.moe/axelterizaki/ultrastar2ass.git/': The requested URL returned error: 500

$ git push -u origin master
fatal: unable to access 'https://lab.shelter.moe/axelterizaki/ultrastar2ass.git/': The requested URL returned error: 500

$ git push -u origin master
Counting objects: 24, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (24/24), 25.73 KiB | 0 bytes/s, done.
Total 24 (delta 1), reused 0 (delta 0)
error: RPC failed; HTTP 500 curl 22 The requested URL returned error: 500 Internal Server Error
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date

$ git push -u origin master
fatal: unable to access 'https://lab.shelter.moe/axelterizaki/ultrastar2ass.git/': The requested URL returned error: 500

$ git push -u origin master
fatal: unable to access 'https://lab.shelter.moe/axelterizaki/ultrastar2ass.git/': The requested URL returned error: 500

$ git push -u origin master
Counting objects: 24, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (24/24), 25.73 KiB | 0 bytes/s, done.
Total 24 (delta 1), reused 0 (delta 0)
To https://lab.shelter.moe/axelterizaki/ultrastar2ass.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

What is the expected correct behavior?

It should be working all right as in 12.1.x

This happened ever since I upgraded Omnibus gitlab to 12.2 this morning.

Relevant logs and/or screenshots

I examined the production.log and here’s what I found when trying a git push :

Started GET "/axelterizaki/ultrastar2ass.git/info/refs?service=git-receive-pack" for 192.168.122.1 at 2019-08-23 12:55:18 +0200
Processing by Gitlab::RequestForgeryProtection::Controller#index as */*
  Parameters: {"service"=>"git-receive-pack"}
Completed 200 OK in 0ms (ActiveRecord: 0.0ms)

Redis::CommandError (ERR value is not an integer or out of range):

lib/peek/views/redis_detailed.rb:10:in `call'
lib/gitlab/middleware/read_only/controller.rb:40:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:26:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:29:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'

Here it says it returned a 200, but my Apache frontend server returns a 500 instead :

xx.xxx.xx.xxx - - [23/Aug/2019:13:03:05 +0200] "GET /axelterizaki/ultrastar2ass.git/info/refs?service=git-receive-pack HTTP/1.1" 500 3228 "-" "git/2.19.0.windows.1"

I’m not sure what’s wrong but I guess the Redis error in production.log has something to do with it.

Output of checks

See below

Results of GitLab environment info

Expand for output related to GitLab environment info

System information System: Ubuntu 16.04 Current User: git Using RVM: no Ruby Version: 2.6.3p62 Gem Version: 2.7.9 Bundler Version:1.17.3 Rake Version: 12.3.2 Redis Version: 3.2.12 Git Version: 2.22.0 Sidekiq Version:5.2.7 Go Version: unknown

GitLab information Version: 12.2.0 Revision: 1c1d47c5974 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 10.9 URL: https://lab.shelter.moe HTTP Clone URL: https://lab.shelter.moe/some-group/some-project.git SSH Clone URL: git@shelter.mahoro-net.org:some-group/some-project.git Using LDAP: no Using Omniauth: yes Omniauth Providers: gitlab, google_oauth2, twitter, github

GitLab Shell Version: 9.3.0 Repository storage paths:

default: /var/opt/gitlab/git-data/repositories
GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 9.3.0 ? ... OK (9.3.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK

Access to /var/opt/gitlab/.ssh/authorized_keys: OK gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Checking Reply by email ...

IMAP server credentials are correct? ... yes Init.d configured correctly? ... skipped MailRoom running? ... skipped

Checking Reply by email ... Finished

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 5/2 ... yes 2/4 ... yes 1/6 ... yes 1/7 ... yes 1/8 ... yes 7/9 ... yes 19/10 ... yes 4/11 ... yes 22/12 ... yes 156/13 ... yes 15/14 ... yes 8/15 ... yes 5/18 ... yes 45/22 ... yes 156/23 ... yes 52/24 ... yes 52/25 ... yes 59/26 ... yes 155/28 ... yes 62/32 ... yes 62/33 ... yes 52/34 ... yes 155/35 ... yes 5/36 ... yes 54/40 ... yes 67/41 ... yes 67/43 ... yes 67/44 ... yes 156/45 ... yes 65/46 ... yes 66/47 ... yes 82/52 ... yes 96/55 ... yes 82/59 ... yes 8/65 ... yes 7/66 ... yes 5/67 ... yes 5/68 ... yes 82/69 ... yes 20/70 ... yes 45/71 ... yes 110/72 ... yes 82/73 ... yes 8/74 ... yes 8/75 ... yes 8/76 ... yes 156/77 ... yes 9/80 ... yes 66/81 ... yes 78/83 ... yes 1/87 ... yes 135/89 ... yes 126/90 ... yes 135/91 ... yes 135/92 ... yes 135/93 ... yes 1/98 ... yes 153/99 ... yes 155/100 ... yes 155/101 ... yes 5/102 ... yes 20/104 ... yes 8/106 ... yes 45/107 ... yes 102/109 ... yes 129/110 ... yes 5/111 ... yes 9/112 ... yes 198/113 ... yes 102/114 ... yes 198/115 ... yes 193/116 ... yes 202/117 ... yes 45/118 ... yes 135/119 ... yes 107/120 ... yes 107/121 ... yes 20/123 ... yes 5/129 ... yes 135/130 ... yes 5/131 ... yes 52/132 ... yes 1/133 ... yes 1/134 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.5.3 ? ... yes (2.6.3) Git version >= 2.22.0 ? ... yes (2.22.0) Git user has default SSH configuration? ... yes Active users: ... 196

Checking GitLab App ... Finished

Checking GitLab subtasks ... Finished

Possible fixes

For now my only possible workaround is to migrate back to an older version (12.1) where this didn’t happen.

Источник