doc-locale/fr-fr/topics/git/troubleshooting_git.md
{{< details >}}
{{< /details >}}
Il arrive que les choses ne fonctionnent pas comme prévu lorsque vous utilisez Git. Voici quelques conseils pour dépanner et résoudre les problèmes liés à Git.
Lors du débogage de problèmes Git sur un serveur GitLab, utilisez /opt/gitlab/embedded/bin/git plutôt que le binaire git fourni par le système, qui pourrait être plus ancien.
GIT_SSH_COMMAND="ssh -i ~/.ssh/gitlabadmin" git <command>
Remplacez <command> par la commande Git que vous souhaitez exécuter.
GIT_SSH_COMMAND="ssh -vvv" git clone <git@url> 2>&1 \
| tee /tmp/gitlab-clone-test.log
Remplacez <git@url> par l'URL SSH de votre dépôt. La sortie est enregistrée dans /tmp/gitlab-clone-test.log.
GIT_TRACE_PACKET=1 GIT_TRACE=2 GIT_CURL_VERBOSE=1 git clone <url> 2>&1 \
| tee /tmp/gitlab-clone-test.log
Remplacez <url> par l'URL HTTPS de votre dépôt. La sortie est enregistrée dans /tmp/gitlab-clone-test.log.
Git inclut un ensemble complet de traces pour le débogage des commandes Git, par exemple :
GIT_TRACE_PERFORMANCE=1 : active le traçage des données de performance, indiquant la durée de chaque invocation de git.GIT_TRACE_SETUP=1 : active le traçage de ce que git découvre sur le dépôt et l'environnement avec lequel il interagit.GIT_TRACE_PACKET=1 : active le traçage au niveau des paquets pour les opérations réseau.GIT_CURL_VERBOSE=1 : active la sortie détaillée de curl, qui peut inclure des identifiants.Broken pipe lors de git push {#broken-pipe-errors-on-git-push}Des erreurs Broken pipe peuvent se produire lors d'une tentative de push vers un dépôt distant. Lors d'un push, vous verrez généralement :
Write failed: Broken pipe
fatal: The remote end hung up unexpectedly
Pour résoudre ce problème, voici quelques solutions possibles.
Lorsque vous tentez de pousser de grands dépôts avec Git via HTTPS, vous pourriez obtenir un message d'erreur tel que :
fatal: pack has bad object at offset XXXXXXXXX: inflate returned -5
Pour résoudre ce problème :
Augmentez la valeur de http.postBuffer dans votre configuration Git locale. La valeur par défaut est 1 Mo. Par exemple, si git clone échoue lors du clonage d'un dépôt de 500 Mo, exécutez ce qui suit :
Ouvrez un terminal ou une invite de commandes.
Augmentez la valeur de http.postBuffer :
# Set the http.postBuffer size in bytes
git config http.postBuffer 524288000
Si la configuration locale ne résout pas le problème, vous devrez peut-être modifier la configuration du serveur. Cette opération doit être effectuée avec précaution et uniquement si vous disposez d'un accès au serveur.
Augmentez http.postBuffer côté serveur :
Ouvrez un terminal ou une invite de commandes.
Modifiez le fichier gitlab.rb de l'instance GitLab :
gitaly['configuration'] = {
# ...
git: {
# ...
config: [
# Set the http.postBuffer size, in bytes
{key: "http.postBuffer", value: "524288000"},
],
},
}
Appliquez le changement de configuration :
sudo gitlab-ctl reconfigure
stream 0 was not closed cleanly {#error-stream-0-was-not-closed-cleanly}Si vous voyez cette erreur, elle peut être causée par une connexion Internet lente :
RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
Si vous utilisez Git via HTTP plutôt que SSH, essayez l'une de ces solutions :
git config http.postBuffer 52428800.HTTP/1.1 avec git config http.version HTTP/1.1.Si aucune de ces approches ne corrige l'erreur, vous aurez peut-être besoin d'un fournisseur d'accès Internet différent.
Si vous effectuez un push via SSH, vérifiez d'abord votre configuration SSH, car les erreurs « Broken pipe » peuvent parfois être causées par des problèmes sous-jacents liés à SSH (tels que l'authentification). Assurez-vous que SSH est correctement configuré en suivant les instructions de la documentation de dépannage SSH.
Si vous êtes un administrateur GitLab disposant d'un accès au serveur, vous pouvez également éviter les délais d'expiration de session en configurant SSH keep-alive sur le client ou le serveur.
[!note] La configuration des deux côtés (client et serveur) est inutile.
Pour configurer SSH côté client :
Sur UNIX, modifiez ~/.ssh/config (créez le fichier s'il n'existe pas) et ajoutez ou modifiez :
Host your-gitlab-instance-url.com
ServerAliveInterval 60
ServerAliveCountMax 5
Sur Windows, si vous utilisez PuTTY, accédez aux propriétés de votre session, puis allez dans Connexion et sous Sending of null packets to keep session active, définissez Seconds between keepalives (0 to turn off) sur 60.
Pour configurer SSH côté serveur, modifiez /etc/ssh/sshd_config et ajoutez :
ClientAliveInterval 60
ClientAliveCountMax 5
git repack {#running-a-git-repack}Si des erreurs de type « pack-objects » s'affichent également, vous pouvez essayer d'exécuter un git repack avant de tenter à nouveau un push vers le dépôt distant :
git repack
git push
Si vous utilisez une ancienne version de Git (< 2.9), envisagez de passer à la version >= 2.9. Pour plus d'informations, consultez broken pipe when pushing to Git repository.
ssh_exchange_identification {#ssh_exchange_identification-error}Les utilisateurs peuvent rencontrer l'erreur suivante lors d'une tentative de push ou de pull avec Git via SSH :
Please make sure you have the correct access rights
and the repository exists.
...
ssh_exchange_identification: read: Connection reset by peer
fatal: Could not read from remote repository.
ou
ssh_exchange_identification: Connection closed by remote host
fatal: The remote end hung up unexpectedly
ou
kex_exchange_identification: Connection closed by remote host
Connection closed by x.x.x.x port 22
Cette erreur indique généralement que la valeur MaxStartups du démon SSH limite les connexions SSH. Ce paramètre spécifie le nombre maximum de connexions simultanées non authentifiées au démon SSH. Cela affecte les utilisateurs disposant d'identifiants d'authentification appropriés (clés SSH), car chaque connexion est « non authentifiée » au départ. La valeur par défaut est 10.
Cela peut être vérifié en examinant les journaux sshd de l'hôte. Pour les systèmes de la famille Debian, consultez /var/log/auth.log, et pour les dérivés RHEL, vérifiez /var/log/secure pour les erreurs suivantes :
sshd[17242]: error: beginning MaxStartups throttling
sshd[17242]: drop connection #1 from [CLIENT_IP]:52114 on [CLIENT_IP]:22 past MaxStartups
L'absence de cette erreur indique que le démon SSH ne limite pas les connexions, ce qui suggère que le problème sous-jacent est peut-être lié au réseau.
Augmentez MaxStartups sur le serveur GitLab en ajoutant ou en modifiant la valeur dans /etc/ssh/sshd_config :
MaxStartups 100:30:200
100:30:200 signifie que jusqu'à 100 sessions SSH sont autorisées sans restriction, après quoi 30 % des connexions sont rejetées jusqu'à atteindre un maximum absolu de 200.
Après avoir modifié la valeur de MaxStartups, vérifiez si la configuration contient des erreurs.
sudo sshd -t -f /etc/ssh/sshd_config
Si la vérification de la configuration se déroule sans erreur, il devrait être possible de redémarrer le démon SSH en toute sécurité pour que la modification prenne effet.
# Debian/Ubuntu
sudo systemctl restart ssh
# CentOS/RHEL
sudo service sshd restart
git push / git pull {#timeout-during-git-push--git-pull}Si un pull ou un push depuis/vers votre dépôt prend plus de 50 secondes, un délai d'expiration est déclenché. Il contient un journal du nombre d'opérations effectuées et de leurs durées respectives, comme dans l'exemple ci-dessous :
remote: Running checks for branch: master
remote: Scanning for LFS objects... (153ms)
remote: Calculating new repository size... (canceled after 729ms)
Ces informations peuvent être utilisées pour mieux analyser quelle opération est peu performante et fournir à GitLab davantage d'informations sur la façon d'améliorer le service.
Operation timed out {#error-operation-timed-out}Si vous rencontrez une erreur de ce type lors de l'utilisation de Git, cela indique généralement un problème réseau :
ssh: connect to host gitlab.com port 22: Operation timed out
fatal: Could not read from remote repository
Pour aider à identifier le problème sous-jacent :
traceroute et ping : mtr -T -P 22 <gitlab_server>.com. Pour en savoir plus sur MTR et comment interpréter sa sortie, consultez l'article Cloudflare sur My Traceroute (MTR).transfer closed with outstanding read data remaining {#error-transfer-closed-with-outstanding-read-data-remaining}Parfois, lors du clonage d'anciens dépôts ou de dépôts volumineux, l'erreur suivante s'affiche lors de l'exécution de git clone via HTTP :
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Ce problème est courant dans Git lui-même, en raison de son incapacité à gérer des fichiers volumineux ou de grandes quantités de fichiers. Git LFS a été créé pour contourner ce problème ; cependant, il présente lui aussi des limitations. Cela est généralement dû à l'une des raisons suivantes :
Si cette erreur se produit lors du clonage d'un dépôt volumineux, vous pouvez diminuer la profondeur de clonage à une valeur de 1. Par exemple :
Cette approche ne résout pas la cause sous-jacente, mais vous permet de cloner le dépôt avec succès. Pour diminuer la profondeur de clonage à 1, exécutez :
variables:
GIT_DEPTH: 1
Your password expired lors d'un Git fetch via SSH pour un utilisateur LDAP {#your-password-expired-error-on-git-fetch-with-ssh-for-ldap-user}{{< details >}}
{{< /details >}}
Si git fetch renvoie cette erreur HTTP 403 Forbidden sur GitLab Self-Managed, la date d'expiration du mot de passe (users.password_expires_at) de cet utilisateur dans la base de données GitLab est une date passée :
Your password expired. Please access GitLab from a web browser to update your password.
Les requêtes effectuées avec un compte SSO et pour lesquelles password_expires_at n'est pas null renvoient cette erreur :
"403 Forbidden - Your password expired. Please access GitLab from a web browser to update your password."
Pour résoudre ce problème, vous pouvez mettre à jour la date d'expiration du mot de passe de l'une des façons suivantes :
En utilisant la console GitLab Rails pour vérifier et mettre à jour les données utilisateur :
user = User.find_by_username('<USERNAME>')
user.password_expired?
user.password_expires_at
user.update!(password_expires_at: nil)
En utilisant gitlab-psql :
# gitlab-psql
UPDATE users SET password_expires_at = null WHERE username='<USERNAME>';
Le bug a été signalé dans le ticket 332455.
HTTP Basic: Access Denied {#error-on-git-fetch-http-basic-access-denied}Si vous recevez une erreur HTTP Basic: Access denied lors de l'utilisation de Git via HTTP(S), consultez le guide de dépannage de l'authentification à deux facteurs.
Cette erreur peut également se produire avec Git for Windows 2.46.0 et versions ultérieures. Lors de l'authentification avec un jeton, le nom d'utilisateur peut être n'importe quelle valeur, mais une valeur vide pourrait déclencher l'erreur d'authentification.
Pour résoudre ce problème, spécifiez une chaîne de nom d'utilisateur. Utilisez l'une des méthodes suivantes, en remplaçant <USERNAME> par votre nom d'utilisateur GitLab :
Lors du clonage d'un dépôt :
git clone https://<USERNAME>@gitlab.com/path/to/a/project.git
Mettre à jour l'URL d'un remote existant :
git remote set-url origin https://<USERNAME>@gitlab.com/path/to/a/project.git
Configurer Git pour toujours utiliser un nom d'utilisateur pour un hôte spécifique :
git config --global url."https://<USERNAME>@gitlab.com/".insteadOf "https://gitlab.com/"
401 enregistrées lors d'un git clone réussi {#401-errors-logged-during-successful-git-clone}{{< details >}}
{{< /details >}}
Lors du clonage d'un dépôt via HTTP, le fichier production_json.log peut afficher un statut initial de 401 (non autorisé), suivi rapidement d'un 200.
{
"method":"GET",
"path":"/group/project.git/info/refs",
"format":"*/*",
"controller":"Repositories::GitHttpController",
"action":"info_refs",
"status":401,
"time":"2023-04-18T22:55:15.371Z",
"remote_ip":"x.x.x.x",
"ua":"git/2.39.2",
"correlation_id":"01GYB98MBM28T981DJDGAD98WZ",
"duration_s":0.03585
}
{
"method":"GET",
"path":"/group/project.git/info/refs",
"format":"*/*",
"controller":"Repositories::GitHttpController",
"action":"info_refs",
"status":200,
"time":"2023-04-18T22:55:15.714Z",
"remote_ip":"x.x.x.x",
"user_id":1,
"username":"root",
"ua":"git/2.39.2",
"correlation_id":"01GYB98MJ0CA3G9K8WDH7HWMQX",
"duration_s":0.17111
}
Cette entrée initiale 401 dans le journal est attendue pour chaque opération Git effectuée via HTTP, en raison du fonctionnement de l'authentification HTTP basic.
Lorsque le client Git initie un clonage, la requête initiale envoyée à GitLab ne fournit aucune information d'authentification. GitLab renvoie un résultat 401 Unauthorized pour cette requête. Quelques millisecondes plus tard, le client Git envoie une requête de suivi contenant les informations d'authentification. Cette deuxième requête devrait réussir et produire une entrée de journal 200 OK.
Si une entrée de journal 401 ne dispose pas d'une entrée de journal 200 correspondante, le client Git utilise probablement :
Si ce problème n'est pas corrigé, vous pourriez rencontrer des erreurs 403 (Forbidden) à la place.
403 lors d'opérations Git via HTTP {#403-error-when-performing-git-operations-over-http}Lors d'opérations Git via HTTP, une erreur 403 (Forbidden) indique que votre adresse IP a été bloquée par l'interdiction suite à des échecs d'authentification :
fatal: unable to access 'https://gitlab.com/group/project.git/': The requested URL returned error: 403
Les limites de l'interdiction suite à des échecs d'authentification diffèrent selon que vous utilisez GitLab Self-Managed ou GitLab.com.
{{< details >}}
{{< /details >}}
L'erreur 403 peut être observée dans le fichier production_json.log :
{
"method":"GET",
"path":"/group/project.git/info/refs",
"format":"*/*",
"controller":"Repositories::GitHttpController",
"action":"info_refs",
"status":403,
"time":"2023-04-19T22:14:25.894Z",
"remote_ip":"x.x.x.x",
"user_id":1,
"username":"root",
"ua":"git/2.39.2",
"correlation_id":"01GYDSAKAN2SPZPAMJNRWW5H8S",
"duration_s":0.00875
}
Si votre adresse IP a été bloquée, une entrée de journal correspondante existe dans le fichier auth_json.log :
{
"severity":"ERROR",
"time":"2023-04-19T22:14:25.893Z",
"correlation_id":"01GYDSAKAN2SPZPAMJNRWW5H8S",
"message":"Rack_Attack",
"env":"blocklist",
"remote_ip":"x.x.x.x",
"request_method":"GET",
"path":"/group/project.git/info/refs?service=git-upload-pack"}