GitLab CE’de ‘runsv not running’ Hatası Nasıl Giderilir?

GitLab CE sunucunuz aniden çalışmayı durdurduğunda veya bir yükseltme sonrasında beklenmedik bir şekilde çevrimdışı olduğunda, karşınızda “runsv not running” hatasını görmek can sıkıcı olabilir. Bu kapsamlı rehber, bu yaygın ve kritik hatanın altında yatan nedenleri anlamanıza, adım adım gidermenize ve gelecekte benzer sorunları önlemenize yardımcı olacak.

GitLab Community Edition (CE) kullanıcıları için, sunucunun sorunsuz çalışması kritik öneme sahiptir. Ancak bazen, özellikle sistem yükseltmeleri, disk doluluğu veya beklenmedik sistem çöküşleri sonrasında, “runsv not running” gibi bir hata mesajıyla karşılaşmak iş akışınızı sekteye uğratabilir. Bu hata, GitLab’ın temel süreç yönetimi mekanizması olan Runit’in veya onunla ilişkili runsv yardımcı programının düzgün çalışmadığını gösterir. Peki, bu tam olarak ne anlama geliyor ve neden ortaya çıkar?

GitLab, Omnibus paketi aracılığıyla kurulduğunda, birçok bileşeni (Nginx, PostgreSQL, Redis, Unicorn/Puma vb.) tek bir pakette birleştirir. Bu bileşenlerin sorunsuz bir şekilde başlatılması, izlenmesi ve yönetilmesi için Runit adında hafif bir initsistem kullanılır. Runit, servislerin başlatılmasını, durdurulmasını ve bir hata durumunda otomatik olarak yeniden başlatılmasını sağlayan robust bir sistemdir. Runit’in çekirdek bileşenlerinden biri olan runsv, her bir servisin yaşam döngüsünü yöneten ayrı bir süreçtir. Yani, bir GitLab servisi (örneğin, Nginx veya GitLab Rails) çalıştığında, arka planda o servisi izleyen ve yöneten bir runsv süreci bulunur. Eğer runsv kendisi çalışmıyorsa veya yönetmesi gereken servisle bağlantısı kesilmişse, “runsv not running” hatasıyla karşılaşırsınız.

Bu hatanın ortaya çıkmasının birkaç yaygın nedeni vardır. İlk olarak, kaynak yetersizliği sıklıkla karşılaşılan bir durumdur. Sunucunuzun belleği (RAM) tükenmişse, CPU’su aşırı yüklenmişse veya disk alanı kalmamışsa, runsv veya diğer kritik GitLab servisleri başlatılamaz ya da çalışmaya devam edemez. Özellikle disk doluluğu, log dosyalarının yazılamamasına ve bu durumun zincirleme bir reaksiyonla servislerin çökmesine neden olabilir. İkinci olarak, bozuk veya hatalı konfigürasyon dosyaları da bu hataya yol açabilir. /etc/gitlab/gitlab.rb dosyasında yapılan yanlış bir değişiklik veya bir yükseltme sırasında oluşan bir uyumsuzluk, Runit’in servisleri doğru bir şekilde başlatmasını engelleyebilir. Üçüncü bir neden, sistem yükseltmeleri sırasında ortaya çıkan sorunlardır. Bazen, GitLab veya işletim sistemi yükseltmeleri, Runit’in kullandığı cache dosyalarını bozabilir veya servis tanımlarında uyumsuzluklara neden olabilir. Dördüncü olarak, dosya izinleri ve sahiplik sorunları da kritik olabilir. GitLab bileşenlerinin veya log dosyalarının doğru izinlere sahip olmaması, runsv‘nin gerekli dosyalara erişimini engelleyebilir. Son olarak, nadiren de olsa, çekirdek sorunları veya donanımsal arızalar gibi daha derin sistem seviyesi problemler de bu hatanın nedeni olabilir. Bu nedenleri anlamak, doğru teşhis koymak ve etkili bir çözüm bulmak için ilk adımdır.

GitLab CE’de runsv Durumunu Nasıl Kontrol Ederiz?

“runsv not running” hatasıyla karşılaştığınızda, ilk yapmanız gereken şey, GitLab servislerinin mevcut durumunu kontrol etmektir. Bu, sorunun kökenini anlamak ve doğru çözüm adımlarını belirlemek için hayati öneme sahiptir. GitLab Omnibus paketi, bu tür durumları yönetmek için güçlü komut satırı araçları sunar. Özellikle gitlab-ctl aracı, servislerinizi yönetmek ve durumlarını kontrol etmek için merkezi bir noktadır.

GitLab servislerinin genel durumunu hızlıca kontrol etmek için aşağıdaki komutu kullanabilirsiniz:

gitlab-ctl status

Bu komutun çıktısı, sunucunuzdaki tüm GitLab bileşenlerinin (Nginx, PostgreSQL, Redis, Sidekiq, Unicorn/Puma, Gitaly vb.) ve ilgili runsv süreçlerinin durumunu gösterecektir. Normal bir durumda, her servisin yanında "run" veya "ready" gibi bir ifade görmelisiniz. Ancak "runsv not running" hatasıyla karşılaşıyorsanız, bir veya daha fazla servisin yanında "down", "not running" veya benzer bir hata durumu görebilirsiniz. Örneğin, çıktı şöyle görünebilir:

run: logrotate: (pid 1234) 639s; run: logrotate: (pid 1234) 639s;
down: nginx: 0s, normally up, want: up
down: postgresql: 0s, normally up, want: up
run: redis: (pid 5678) 639s; run: redis: (pid 5678) 639s;

Yukarıdaki örnekte, Nginx ve PostgreSQL servislerinin "down" durumda olduğu açıkça görülmektedir. Bu, ilgili runsv süreçlerinin bu servisleri yönetemediği veya başlatamadığı anlamına gelir.

Daha detaylı bilgi edinmek isterseniz, Runit'in doğrudan sv komutunu kullanarak her bir servisin altındaki runsv durumunu kontrol edebilirsiniz. GitLab Omnibus kurulumunda servisler genellikle /opt/gitlab/sv/ dizini altında bulunur:

sv status /opt/gitlab/sv/*

Bu komut, her bir servisin ayrı ayrı "up" mı "down" mı olduğunu ve ne kadar süredir bu durumda olduğunu gösterir. Örneğin, "runsv not running" hatasıyla ilişkili bir çıktı şöyle olabilir:

down: /opt/gitlab/sv/gitaly: 0s, normally up
down: /opt/gitlab/sv/nginx: 0s, normally up

Bu çıktı, Gitaly ve Nginx servislerinin beklenen şekilde çalışmadığını ve runsv süreçlerinin bu servisleri yönetemediğini teyit eder. Bu detaylı kontrol, hangi spesifik bileşenin sorun yaşadığını anlamanıza yardımcı olur.

Servislerin durumunu kontrol ettikten sonra, bir sonraki kritik adım log dosyalarını incelemektir. GitLab, tüm bileşenlerinin loglarını /var/log/gitlab/ dizini altında tutar. Her servisin (örneğin, gitlab-rails, nginx, postgresql, redis) kendi alt dizini ve içerisinde current adlı bir sembolik bağlantı ile mevcut log akışını gösteren bir dosyası bulunur. Özellikle runsv hatalarında, ilgili servisin loglarına bakmak, hatanın temel nedenine dair ipuçları sağlayabilir. Örneğin, Nginx ile ilgili bir sorun varsa, /var/log/gitlab/nginx/current dosyasını incelemeniz gerekir. Bu log dosyaları, diskin dolu olması, izin sorunları, konfigürasyon hataları veya başka bir uygulama hatası gibi sorunları gösterebilir. svlogd, Runit'in log yönetimi bileşenidir ve logları düzgün bir şekilde toplamakla sorumludur; bu da logların sağlıklı bir şekilde yazılıp yazılamadığına dair önemli bilgiler sunabilir.

Bu kontroller, sorunu teşhis etmenin temelini oluşturur. Hangi servislerin çalışmadığını ve ilgili loglarda ne gibi hatalar olduğunu belirledikten sonra, hatayı gidermeye yönelik adımlara geçebilirsiniz.

"runsv not running" Hatasını Adım Adım Giderme Rehberi

GitLab CE'de "runsv not running" hatasıyla karşılaştığınızda panik yapmak yerine, sistematik bir yaklaşımla sorunu çözebilirsiniz. Bu bölüm, adım adım bir rehber sunarak sizi teşhis ve onarım sürecinde yönlendirecektir.

Adım 1: Temel Sistem Kontrolleri ve Kaynak Analizi

Bir "runsv not running" hatası çoğu zaman temel sistem kaynaklarındaki bir eksiklikten kaynaklanır. Bu nedenle, ilk olarak sunucunuzun temel sağlık durumunu kontrol etmelisiniz.

• Disk Alanı Kontrolü: GitLab, özellikle log dosyaları ve veri depolama için önemli miktarda disk alanı kullanır. Diskinizin dolup dolmadığını kontrol etmek kritik öneme sahiptir.

  
  df -h
          

  Eğer diskinizin %90 veya daha fazlası doluysa, bu durum runsv'nin logları yazamama veya servisleri başlatamama sorunlarına yol açabilir. Gereksiz dosyaları temizleyerek veya disk alanını genişleterek bu sorunu çözmeniz gerekebilir.

• Bellek ve CPU Kullanımı: Bellek yetersizliği veya yüksek CPU kullanımı, servislerin düzgün çalışmasını engelleyebilir.

  
  top
          

  veya

  
  htop
          

  komutlarıyla bellek ve CPU kullanımını kontrol edin. Eğer sunucu aşırı yüklenmişse, bazı GitLab bileşenlerinin başlatılamaması veya çökmesi olasıdır. Gerekirse, gereksiz süreçleri durdurun veya sunucu kaynaklarını artırmayı düşünün.

• Sistem Günlükleri: İşletim sistemi seviyesindeki hatalar da GitLab servislerini etkileyebilir. Sistem günlüklerini kontrol ederek genel bir fikir edinin.

  
  journalctl -xe
          

  veya

  
  dmesg | less
          

  komutları, son sistem olaylarını ve çekirdek mesajlarını göstererek potansiyel donanım sorunları, bellek hataları veya diğer kritik sistem uyarıları hakkında bilgi sağlayabilir.

Bu temel kontroller, hatanın doğrudan sistem kaynaklarıyla ilgili olup olmadığını anlamanıza yardımcı olacaktır. Eğer kaynak kısıtlamaları tespit ederseniz, öncelikle bu sorunları gidermelisiniz.

Adım 2: GitLab Servislerini Yeniden Başlatma ve Kontrol Etme

Temel sistem kontrolleri sonrasında bir sorun tespit etmezseniz veya kaynak sorunlarını giderdiyseniz, GitLab servislerini yeniden başlatmayı deneyin. Bu, birçok geçici sorunu çözebilir.

• Servisleri Durdurma: Tüm GitLab servislerini düzenli bir şekilde durdurun.

  
  gitlab-ctl stop
          

  Bu komut, tüm Runit tarafından yönetilen servisleri durduracaktır. Eğer servisler takılırsa, birkaç dakika bekleyin. Durdurma işlemi tamamlandığında, tekrar gitlab-ctl status komutunu çalıştırarak tüm servislerin "down" olduğundan emin olun.

• Konfigürasyonu Yeniden Uygulama: GitLab konfigürasyonunu yeniden uygulamak, bazen bozuk veya eksik konfigürasyon ayarlarını düzeltebilir.

  
  gitlab-ctl reconfigure
          

  Bu komut, /etc/gitlab/gitlab.rb dosyasındaki ayarları okur ve tüm GitLab bileşenlerini bu ayarlara göre yeniden yapılandırır. Bu işlem sırasında herhangi bir hata mesajı alıp almadığınıza dikkat edin.

• Servisleri Başlatma: Yeniden yapılandırmadan sonra, servisleri başlatın.

  
  gitlab-ctl start
          

  Servislerin başlatılması birkaç dakika sürebilir. Başlatma işlemi tamamlandıktan sonra, tekrar gitlab-ctl status komutunu kullanarak tüm servislerin "run" veya "ready" durumda olduğundan emin olun.

Bu adımlar, genellikle küçük konfigürasyon tutarsızlıkları veya geçici takılmaları gidermede etkilidir. Eğer servisler hala başlamazsa, daha derinlemesine incelemeye geçmelisiniz.

Adım 3: Konfigürasyon Dosyalarını İnceleme ve Düzenleme

Hatalı bir konfigürasyon, "runsv not running" hatasının yaygın bir nedenidir. Özellikle son yapılan değişiklikler veya yükseltmelerden sonra bu durumu kontrol etmek önemlidir.

• /etc/gitlab/gitlab.rb Dosyasını Kontrol Etme: Bu dosya, GitLab'ın ana konfigürasyon dosyasıdır. Yakın zamanda yaptığınız değişiklikleri gözden geçirin. Özellikle yeni eklediğiniz veya değiştirdiğiniz ayarlar, uyumsuzluklara neden olabilir.

  
  sudo vim /etc/gitlab/gitlab.rb
          

  veya favori editörünüzle açın. Eğer yakın zamanda bir değişiklik yaptıysanız ve bu hatayı tetiklediyse, o değişikliği geçici olarak geri almayı deneyin. Hatayı bulmak için satır satır yorum satırına alarak (# ile) test edebilirsiniz.

• Önceki Yedeklerden Geri Yükleme: Eğer kritik bir konfigürasyon hatasından şüpheleniyorsanız ve bir yedeğiniz varsa, /etc/gitlab/gitlab.rb dosyasının bilinen iyi bir sürümünü geri yüklemek en güvenli yoldur.

  
  sudo cp /etc/gitlab/gitlab.rb.bak /etc/gitlab/gitlab.rb
          

  (Eğer bir yedeğiniz varsa). Geri yükledikten sonra gitlab-ctl reconfigure ve ardından gitlab-ctl start komutlarını çalıştırmayı unutmayın.

Vaka Analizi: Disk Doluluğu ve runsv Sorunu

Bir keresinde, bir müşterimizin GitLab CE sunucusu "runsv not running" hatasıyla aniden çevrimdışı kaldı. Sunucunun disk alanını kontrol ettiğimizde (df -h), /var/log dizininin bulunduğu bölümün %100 dolu olduğunu gördük. GitLab servisleri, özellikle svlogd, log dosyalarını sürekli olarak yazmaya çalışıyordu ancak diskte boş yer kalmadığı için bu işlem başarısız oluyordu. Bu durum, svlogd sürecinin kendisinin veya onunla ilişkili runsv süreçlerinin düzgün çalışmasını engelledi. Log yazılamaması, birçok GitLab bileşeninin hata vermesine ve sonuç olarak Runit'in bu servisleri "down" olarak işaretlemesine yol açtı. Çözüm olarak, eski log dosyalarını temizledik, disk alanını genişlettik ve ardından gitlab-ctl reconfigure ve gitlab-ctl start komutlarını çalıştırdık. Servisler sorunsuz bir şekilde yeniden başladı. Bu örnek, temel sistem kaynaklarının, özellikle disk alanının, GitLab'ın sorunsuz çalışması için ne kadar kritik olduğunu göstermektedir.

Adım 4: Bozuk Runit Cache'ini Onarma

Bazen, Runit'in servislerle ilgili dahili durum veya cache dosyaları bozulabilir. Bu, yükseltmeler sırasında veya ani sistem kapatmalarında meydana gelebilir. Bu durumu düzeltmek için Runit cache'ini temizleyip servisleri yeniden başlatmak gerekebilir.

• Tüm GitLab Servislerini Durdurma: Öncelikle, tüm GitLab servislerini güvenli bir şekilde durdurmalısınız.

  
  gitlab-ctl stop
          

• Bozuk Runit Cache Dosyalarını Kaldırma: Runit'in servislerle ilgili durum bilgilerini tuttuğu dosyaları temizleyin. Bu dosyalar genellikle her bir servisin /opt/gitlab/sv//supervise/ dizininde bulunur. Özellikle control dosyalarının kaldırılması, Runit'i bu servisleri yeniden başlatmaya zorlayacaktır.

  
  sudo rm -rf /opt/gitlab/sv/*/supervise/control
          

  Bu komut, tüm servislerin kontrol dosyalarını kaldırır. Dikkatli olun, bu komut kritik sistem dosyalarını silebilir, bu yüzden doğru dizini hedeflediğinizden emin olun.

• GitLab Servislerini Başlatma: Cache dosyaları temizlendikten sonra, GitLab servislerini yeniden başlatın.

  
  gitlab-ctl start
          

  Servisler başladıktan sonra, gitlab-ctl status komutuyla durumlarını kontrol edin. Bu yöntem, özellikle bir yükseltme sonrası "runsv not running" hatasıyla karşılaşıldığında oldukça etkili olabilir.

Adım 5: Gelişmiş Log İncelemesi ve svlogd Sorunları

Yukarıdaki adımlar sorunu çözmezse, log dosyalarına daha derinlemesine bakmanız ve özellikle svlogd ile ilgili olası sorunları araştırmanız gerekir.

• Detaylı Log Analizi: GitLab'ın tüm logları /var/log/gitlab/ dizini altındadır. Hangi servisin "down" olduğunu belirledikten sonra, o servisin log dosyasına odaklanın. Örneğin, gitlab-rails ile ilgili bir sorun varsa:

  
  tail -f /var/log/gitlab/gitlab-rails/current
          

  Bu komut, log dosyasının sonunu sürekli olarak izler, böylece servisleri yeniden başlatırken veya başka işlemler yaparken gerçek zamanlı hata mesajlarını görebilirsiniz. Aynı şekilde, Nginx, PostgreSQL, Redis ve Sidekiq loglarını da kontrol edin. Hata mesajlarında anahtar kelimeler arayın (örneğin, "permission denied", "connection refused", "out of memory", "no space left on device").

• svlogd Durumu: Runit'in log yöneticisi olan svlogd, logları düzgün bir şekilde diske yazmaktan sorumludur. Eğer svlogd çalışmıyorsa veya sorun yaşıyorsa, servislerin logları yazılamaz ve bu da dolaylı olarak runsv hatalarına yol açabilir.

  
  sv status /opt/gitlab/sv/logrotate
          

  (Logrotate, genellikle svlogd ile ilişkilidir, ancak diğer servislerin log dizinlerini de kontrol edebilirsiniz). Eğer svlogd ile ilgili bir sorun varsa, ilgili log dizinlerinin disk alanı ve dosya izinlerini kontrol edin. Log rotasyonunun düzgün çalıştığından emin olun, aksi takdirde eski loglar diski doldurabilir.

Bu gelişmiş log analizi, genellikle sorunun kök nedenini ortaya çıkarır ve daha spesifik bir çözüm bulmanıza olanak tanır. Hata mesajlarını not alın ve gerekirse GitLab'ın dokümantasyonunda veya topluluk forumlarında bu mesajları arayın.

İleri Düzey Çözümler ve Güvenlik İpuçları

Yukarıdaki adımlar çoğu "runsv not running" hatasını gidermede etkili olsa da, bazen daha derinlemesine veya spesifik çözümler gerekebilir. Bu bölüm, deneyimli kullanıcılar için bazı ileri düzey ipuçları ve güvenlik önerileri sunmaktadır.

• Çekirdek Güncellemeleri ve Uyumsuzluk Sorunları: Nadiren de olsa, işletim sistemi çekirdek güncellemeleri, Runit'in veya bazı GitLab bileşenlerinin çalışma şeklini etkileyebilir. Özellikle eski çekirdek sürümleri veya yeni çekirdek sürümlerine yükseltmeler, uyumsuzluklara yol açabilir. Eğer "runsv not running" hatası bir çekirdek güncellemesi sonrası ortaya çıktıysa, eski bir çekirdek sürümüne geri dönmeyi veya GitLab'ın desteklediği çekirdek sürümünü kontrol etmeyi düşünebilirsiniz. Bu tür sorunlar genellikle sistem loglarında (dmesg veya journalctl) çekirdek ile ilgili hata mesajlarıyla belirginleşir.
• SELinux/AppArmor Etkileri: Bazı işletim sistemlerinde (özellikle CentOS/RHEL'de SELinux, Ubuntu/Debian'da AppArmor), varsayılan güvenlik politikaları GitLab'ın bazı dizinlerine veya süreçlerine erişimi engelleyebilir. Bu durum, runsv'nin servisleri başlatmasını veya log dosyalarına yazmasını engelleyebilir ve "permission denied" gibi hatalara yol açabilir. Eğer bu güvenlik mekanizmaları etkinse, geçici olarak devre dışı bırakıp sorunun çözülüp çözülmediğini test edebilir (sadece test amaçlı ve üretim ortamında dikkatli olun!) veya GitLab'ın gerektirdiği izinleri güvenlik politikalarınıza ekleyebilirsiniz. İlgili loglarda "denied" veya "AVC" mesajlarını arayın.
• Yedekleme Stratejileri ve Felaket Kurtarma: "runsv not running" gibi kritik hatalar, düzenli ve güvenilir bir yedekleme stratejisinin ne kadar önemli olduğunu bir kez daha gösterir. GitLab'ın yerleşik yedekleme mekanizmasını (gitlab-rake gitlab:backup:create) düzenli olarak kullanarak veri kaybını önleyin. Ayrıca, yedekleri geri yükleme prosedürlerini (felaket kurtarma planı) test etmek, kritik bir durumda hızlıca ayağa kalkmanızı sağlar. Bu, yalnızca verileri değil, aynı zamanda /etc/gitlab/gitlab.rb gibi konfigürasyon dosyalarını da yedeklemeyi içerir.
• Monitörleme ve Uyarı Sistemleri: GitLab sunucunuzu proaktif olarak izlemek, "runsv not running" gibi sorunların önlenmesinde veya erken teşhisinde büyük rol oynar. Prometheus, Grafana, Zabbix veya benzeri monitörleme araçlarını kullanarak sunucu kaynaklarını (CPU, bellek, disk I/O, disk alanı) ve GitLab servislerinin durumunu (gitlab-ctl status çıktısı gibi) izleyebilirsiniz. Eşik değerler aşıldığında veya bir servis çevrimdışı olduğunda otomatik uyarılar alarak sorunları büyümeden önce çözebilirsiniz.

Bu ileri düzey teknikler ve güvenlik ipuçları, GitLab ortamınızın daha dirençli ve yönetilebilir olmasını sağlar. Unutmayın, proaktif yaklaşım, reaktif olmaktan her zaman daha iyidir.

Sonuç ve Sıkça Sorulan Sorular

GitLab CE'de "runsv not running" hatası, ilk bakışta korkutucu görünse de, genellikle sistematik bir teşhis ve çözüm süreciyle giderilebilir. Bu makale boyunca, hatanın temel nedenlerini, servis durumunu kontrol etme yöntemlerini, adım adım giderme rehberini ve ileri düzey ipuçlarını ele aldık. Temel sistem kaynaklarını kontrol etmek, konfigürasyon dosyalarını incelemek, servisleri doğru bir şekilde yeniden başlatmak ve log dosyalarını analiz etmek, sorunun kökenini bulmada ve kalıcı bir çözüm üretmede en etkili yaklaşımlardır. Düzenli bakım, yedekleme ve proaktif monitörleme, gelecekte bu tür kritik hataları önlemenin anahtarıdır. Unutmayın, her hata bir öğrenme fırsatıdır ve bu süreçte edineceğiniz bilgiler, GitLab ortamınızın daha sağlam olmasına yardımcı olacaktır.

Sıkça Sorulan Sorular (SSS)

Aşağıda, "runsv not running" hatasıyla ilgili sıkça sorulan bazı soruları ve yanıtlarını bulabilirsiniz:

1. "runsv not running" hatası GitLab performansını nasıl etkiler?

   Bu hata, GitLab servislerinin tamamen durmasına neden olduğu için performansı doğrudan ve olumsuz etkiler. GitLab'ın hiçbir bileşeni (web arayüzü, Git depoları, CI/CD, vb.) çalışmayacak ve kullanıcılar sunucuya erişemeyecektir. Dolayısıyla, hatanın giderilmesi, performansın normale dönmesi için mutlak öneme sahiptir.

2. Bu hatayı önlemek için neler yapabilirim?

   Hata önleme için birkaç önemli adım vardır:

   • Düzenli olarak disk alanı, bellek ve CPU kullanımını izleyin.
   • GitLab yükseltmelerinden önce ve önemli konfigürasyon değişikliklerinden sonra gitlab.rb dosyasının yedeğini alın.
   • GitLab'ı düzenli olarak yedekleyin (veritabanı ve konfigürasyon dahil).
   • İşletim sistemi ve GitLab'ın uyumlu olduğundan emin olun.
   • Sunucu kaynaklarının (RAM, CPU, disk) GitLab'ın ihtiyaçları için yeterli olduğundan emin olun.
3. GitLab'ı yeniden kurmak son çare midir?

   Hayır, çoğu durumda "runsv not running" hatası yeniden kurulum gerektirmeden çözülebilir. Yeniden kurulum, ancak diğer tüm teşhis ve çözüm adımları başarısız olduğunda ve veri yedeklerinizden geri yükleme seçeneğiniz mevcut olduğunda düşünülmelidir. Bu makaledeki adımları takip etmek, genellikle yeniden kuruluma gerek kalmadan sorunu gidermenizi sağlayacaktır.

4. Hata devam ederse kime danışmalıyım?

   Eğer yukarıdaki tüm adımları uygulamanıza rağmen sorun devam ediyorsa, GitLab'ın resmi dokümantasyonunu, topluluk forumlarını (örneğin, GitLab Forumları) veya Stack Overflow gibi platformları inceleyebilirsiniz. Hata mesajlarını ve log çıktılarını bu platformlarda paylaşmak, deneyimli kullanıcılardan veya GitLab uzmanlarından yardım almanızı sağlayabilir. Ayrıca, kurumsal bir ortamda çalışıyorsanız, GitLab'ın ücretli destek hizmetlerinden faydalanmayı düşünebilirsiniz.