Another Update Is Currently In Progress Hatası: Takılan Güncelleme Kilidini Kaldırma

Panelde "WordPress 6.x sürümü mevcut" uyarısını gördünüz, Güncellemeler ekranına gidip "Şimdi Güncelle" düğmesine bastınız. Ekran bir an döndü ve sarı bir kutuda tek satırlık bir cevap çıktı: "Another update is currently in progress." Türkçe kurulumlarda aynı satır "Başka bir güncelleme şu anda devam ediyor." şeklinde görünür. Oysa siz başka bir güncelleme başlatmadınız; sitede sizden başka kimse de yok.

Bu ekranın en kafa karıştırıcı yanı, sitenizin bu sırada gayet normal çalışıyor olmasıdır. Ön yüz açılır, panel açılır, yazı yazabilirsiniz. Sadece güncelleme işlemi başlamayı reddeder. Bu yüzden pek çok kişi bunu bir bakım modu takılması sanır ve .maintenance dosyasını aramaya koyulur — o dosya yoktur, çünkü bu bambaşka bir mekanizmadır. .maintenance dosyası güncelleme başladıktan sonra siteyi kapatır; buradaki kilit ise güncellemenin hiç başlamasını engeller. Siteniz "kısa süreliğine bakım için kapalı" ekranında sıkıştıysa doğru adres .maintenance dosyası takıldı yazısıdır.

Aşağıda önce bu kilidin ne olduğunu, kim tarafından yazıldığını ve neden 15 dakika sonra kendiliğinden geçmesi gerektiğini anlatıyorum. Ardından üç yolla nasıl kaldırılacağını gösteriyorum. Ama yazının asıl değeri ikinci yarısında: kilit bir semptomdur, arıza değil. Asıl soru, güncellemenin neden yarıda kaldığıdır. Bellek limiti, süre limiti, dosya izinleri, dolan disk ve yavaş dış bağlantı — bunları düzeltmezseniz kilidi sildikten sonra bir dahaki denemede aynı yere geri dönersiniz.

Bu Kilit Nedir ve Nereye Yazılır#

WordPress bir çekirdek güncellemesine başlamadan önce, aynı anda ikinci bir güncelleme sürecinin çalışmasını engellemek ister. İki güncelleyicinin aynı dosyaları eşzamanlı yazması, yarım kalmış bir çekirdek kurulumu anlamına gelir ve bu, kurtarılması en zor WordPress arızalarından biridir. Bunu önlemek için basit ama etkili bir yöntem kullanır: veritabanına bir kilit satırı yazar.

Kilidin yeri wp_options tablosudur ve adı core_updater.lock. Değeri, kilidin alındığı andaki Unix zaman damgasıdır — yani düz bir tam sayıdır, serileştirilmiş bir veri değil. Satır autoload sütununda no değeriyle oluşturulur, çünkü her sayfa isteğinde belleğe alınmasına gerek yoktur.

Kilit alma işlemi kasıtlı olarak atomiktir: WordPress satırı INSERT IGNORE ile eklemeye çalışır. Ekleme başarılıysa kilit sizindir, güncelleme başlar. Ekleme başarısızsa (yani satır zaten varsa) mevcut değeri okur ve yaşına bakar. Çekirdek güncelleyicisi için tanınan süre 15 dakikadır. Satır 15 dakikadan yeniyse WordPress işlemi reddeder ve gördüğünüz mesajı basar. Satır 15 dakikadan eskiyse kilidin sahipsiz kaldığına hükmeder, siler ve yeniden alır.

Normal akışta güncelleme bittiğinde WordPress satırı kendisi kaldırır. Sorun tam olarak şurada çıkar: PHP süreci güncellemenin ortasında ölürse — ölümcül hata, bellek tükenmesi, zaman aşımı, kullanıcının sekmeyi kapatması — temizleme kodu hiç çalışmaz. Satır diskte kalır ve zaman damgası o anda dondurulur.

Üç mekanizma birbirinden bağımsızdır ve farklı ekranlar üretir. Aynı arızada ikisinin birden takılı kalması mümkündür: güncelleme yarıda ölürse hem .maintenance dosyası hem kilit satırı geride kalabilir. O durumda siteniz bakım ekranında olur ve güncellemeyi yeniden başlatamazsınız.

Önce 15 Dakika Bekleyin: Çoğu Zaman Yeterlidir#

En düşük riskli çözüm hiçbir şey yapmamaktır. Kilit satırı kendi kendini geçersiz kılar; WordPress 15 dakikadan eski bir kaydı zaten yok sayar. Hatayı ilk kez gördüyseniz ve saat kaç olduğunu biliyorsanız, 15 dakika bekleyip Güncellemeler ekranını yenilemek çoğu vakayı kapatır.

Beklerken şunu yapmayın: düğmeye tekrar tekrar basmayın. Her başarısız deneme yeni bir kilit yazmaz, ama sunucuda gereksiz PHP süreci başlatır ve zaten sıkışık olan kaynakları daha da daraltır. Özellikle güncellemenin ilk denemede bellek yetersizliğinden öldüğü senaryolarda, arka arkaya basılan düğmeler tabloyu daha da kötüleştirir.

Kilidin gerçekten ne zaman alındığını görmek isterseniz — yani beklemenin ne kadar süreceğini hesaplamak için — tek bir SQL sorgusu yeter:

SELECT option_id,
       option_name,
       option_value AS zaman_damgasi,
       FROM_UNIXTIME(option_value) AS kilit_zamani,
       NOW() AS simdi
FROM wp_options
WHERE option_name = 'core_updater.lock';

kilit_zamani sütunundaki değer şu andan 15 dakikadan fazla geridiyse kilit zaten geçersizdir ve sorununuz başka yerdedir — büyük ihtimalle bir önbellek katmanı size eski ekranı gösteriyordur ya da hata mesajı auto_updater.lock kaynaklıdır. Sorgu hiç satır döndürmüyorsa kilit yok demektir; bu durumda aşağıdaki "kilit yokken de aynı hatayı alıyorum" bölümüne geçin.

Kilidi phpMyAdmin Üzerinden Kaldırma#

Beklemek istemiyorsanız veya kilit tekrar tekrar oluşuyorsa satırı elle silebilirsiniz. Bu işlem güvenlidir: sildiğiniz şey bir yapılandırma değil, geçici bir işaretleyicidir. Yine de sunucuya yazan her komuttan önce olduğu gibi, veritabanı yedeği almak iyi bir alışkanlıktır.

Adımlar:

1. Hosting kontrol panelinizden phpMyAdmin'i açın ve sitenizin veritabanını seçin.
2. Üstteki SQL sekmesine geçin.
3. Önce satırın var olduğunu doğrulayın, sonra silin:

SELECT option_id, option_name, option_value
FROM wp_options
WHERE option_name IN ('core_updater.lock', 'auto_updater.lock');

DELETE FROM wp_options
WHERE option_name IN ('core_updater.lock', 'auto_updater.lock');

4. Panele dönün, Güncellemeler sayfasını sert yenileyin ve güncellemeyi tekrar başlatın.

Buradaki wp_options adı, wp-config.php dosyanızdaki $table_prefix değerine bağlıdır. Öneğiniz farklıysa tablo adını ona göre yazın; yanlış tabloya sorgu göndermek hata verir ama zarar vermez. Öneği doğrulamak için:

grep table_prefix wp-config.php

Silme işleminden sonra WordPress bir sonraki denemede kilidi sıfırdan alır. Satırın yeniden oluşması normaldir ve iyiye işarettir — güncelleme gerçekten başlamış demektir. Kötü olan, güncelleme bittiği hâlde satırın kalmasıdır.

WP-CLI ile Tek Komutta Temizlemek#

Sunucuda kabuk erişiminiz varsa aynı işi tek satırda, tablo öneğiyle hiç uğraşmadan yapabilirsiniz. WP-CLI öneği wp-config.php dosyasından kendisi okur:

# Kilit var mi, ne zaman alinmis
wp option get core_updater.lock

# Kilidi kaldir
wp option delete core_updater.lock
wp option delete auto_updater.lock

# Guncelleme durumunu kontrol et
wp core check-update

# Guncellemeyi komut satirindan calistir
wp core update

Son komut özellikle değerlidir. Güncellemeyi tarayıcı üzerinden değil doğrudan kabuktan çalıştırdığınızda iki büyük engel ortadan kalkar: web sunucusunun istek zaman aşımı (nginx fastcgi_read_timeout, Apache Timeout) ve tarayıcının bağlantıyı kapatma ihtimali. CLI süreçleri genellikle max_execution_time sınırından da muaftır. Bu yüzden tarayıcıda sürekli yarıda kalan bir güncelleme, komut satırında ilk denemede tamamlanabilir.

Güncelleme sonrasında dosya bütünlüğünü doğrulamak da bir komutluk iştir:

wp core verify-checksums
wp plugin verify-checksums --all

Bu komutlar her çekirdek ve eklenti dosyasının özetini resmi kayıtlarla karşılaştırır. Yarıda kalan bir güncellemeden sonra en çok merak edilen "acaba dosyalar bozuk mu?" sorusunun kesin cevabını verir. WP-CLI kurulumu ve temel kullanımı için WP-CLI kullanımı yazısına bakabilirsiniz.

Asıl Soru: Güncelleme Neden Yarıda Kaldı#

Kilidi kaldırdınız, güncelleme başladı ve yine aynı yerde takıldı. Bu noktada artık kilitle uğraşmayı bırakıp asıl arızayı aramanız gerekir. Çekirdek güncellemesi, tipik bir WordPress isteğinden çok daha ağır bir iştir: yaklaşık 25-30 MB'lık bir arşiv indirilir, geçici klasöre açılır, yüzlerce dosya kopyalanır ve veritabanı şeması güncellenir. Bu zincirin herhangi bir halkası koptuğunda süreç ölür ve kilit geride kalır.

Aşağıdaki tablo, kilidin tekrar oluşmasına yol açan beş nedeni ve her birinin ayırt edici izini gösterir.

Teşhis için ilk yapılacak iş hata kaydını açmaktır. wp-config.php dosyasına şu üç satırı ekleyin (varsa mevcut WP_DEBUG tanımını değiştirin):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Güncellemeyi bir kez daha deneyin, sonra wp-content/debug.log dosyasının son satırlarına bakın. Ölümcül hata varsa nedeni orada yazar ve tahmin yürütmeye gerek kalmaz. İş bittiğinde WP_DEBUG değerini false yapmayı unutmayın.

PHP bellek ve süre limitleri#

En sık suçlu budur, özellikle paylaşımlı hosting paketlerinde. Mevcut değerleri görmek için:

php -i | grep -E "^memory_limit|^max_execution_time|^upload_max_filesize"
wp eval 'echo ini_get("memory_limit") . " / " . ini_get("max_execution_time") . PHP_EOL;'

Çekirdek güncellemesi için 128 MB alt sınırdır; 256 MB rahat çalışır. WordPress yönetici tarafında ayrıca kendi tavanını kullanır, bunu wp-config.php üzerinden yükseltebilirsiniz:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Bu satırlar yalnızca PHP'nin izin verdiği tavana kadar etkilidir; sunucu tarafında memory_limit 128 MB ise buraya 512 yazmanın hiçbir etkisi olmaz. Sunucu tarafındaki değeri nasıl yükselteceğiniz PHP memory limit yazısında ayrıntılı anlatılıyor. max_execution_time için 300 saniye güvenli bir hedeftir; yükseltemiyorsanız güncellemeyi WP-CLI ile çalıştırmak bu sınırı tamamen dolanır.

Disk ve inode doluluğu#

Güncelleme, arşivi geçici bir dizine açar. Disk doluysa arşiv eksik iner ya da açılamaz; süreç ölür, kilit kalır. Sinsi olan tarafı şudur: disk %100 dolmadan da bu hata çıkabilir, çünkü inode (dosya sayısı) kotası ayrı bir sınırdır ve WordPress güncellemesi binlerce küçük dosya yazar.

df -h
df -i
du -sh wp-content/upgrade wp-content/uploads

wp-content/upgrade klasörü, yarıda kalan güncellemelerden kalan çöpü biriktirir ve kimse temizlemez. İçini boşaltmak güvenlidir; WordPress gerektiğinde yeniden oluşturur. Kullanım oranı %100 görünen bir bölüm varsa önce onu çözün — disk dolu hatası yazısı yer açmanın hızlı yollarını anlatıyor.

Dosya izinleri ve sahiplik#

WordPress güncellemeye başlamadan önce dosya sistemine yazıp yazamadığını test eder. Yazamıyorsa ya FTP bilgisi ister ya da yükseltme dizinini oluşturamayıp yarıda kalır. Bu ikinci durumda kilit alınmış ama iş bitmemiştir.

ls -ld wp-content wp-content/upgrade
stat -c '%U:%G %a %n' wp-content wp-config.php
ps -eo user,comm | grep -E "php-fpm|apache2|httpd" | head

Son komut PHP'nin hangi kullanıcıyla çalıştığını gösterir. Bu kullanıcı ile dosya sahibi farklıysa güncelleme her denemede aynı yerde durur. Çözümü izin bitlerini gevşetmek (asla 777 vermeyin) değil, sahipliği hizalamaktır; ayrıntısı FTP bilgisi istiyor yazısında.

Dış bağlantı sorunları#

WordPress güncelleme paketini downloads.wordpress.org adresinden indirir ve sürüm bilgisini api.wordpress.org üzerinden sorar. Sunucudan giden HTTPS bağlantısı yavaşsa veya bir güvenlik duvarı tarafından engelleniyorsa indirme yarıda kalır. Sunucudan test edin:

curl -o /dev/null -s -w "kod:%{http_code} sure:%{time_total}s\n" \
  https://api.wordpress.org/core/version-check/1.7/

Dönen sürenin birkaç saniyeyi aşması ya da kodun 000 gelmesi, giden bağlantıda sorun olduğunu gösterir. Bu genellikle sunucu tarafındaki bir güvenlik duvarı kuralından ya da DNS çözümleme gecikmesinden kaynaklanır.

Kilit Yokken de Aynı Hatayı Alıyorum#

Bazen core_updater.lock satırı gerçekten yoktur ama mesaj devam eder. Üç ihtimal vardır ve üçü de kolayca elenir.

1. Sayfa önbelleği eski ekranı gösteriyor. Bir tam sayfa önbelleği eklentisi ya da CDN, hata mesajının bulunduğu ekranı kaydetmiş olabilir. Gizli sekmede tekrar deneyin, sonra önbelleği temizleyin.

2. Hata auto_updater.lock kaynaklı. Otomatik güncelleme turu için ayrı bir kilit vardır ve süresi 1 saattir. WordPress'in kendi zamanlanmış görevi gece çalışıp yarıda kaldıysa bu satır kalır. Yukarıdaki silme komutları ikisini birden kapsadığı için bu ihtimali zaten elemiş olursunuz.

3. Zamanlanmış görev sırası tıkalı. Güncelleme kontrolü WP-Cron üzerinden yürür; sıradaki görevler birikmişse tuhaf davranışlar ortaya çıkar:

wp cron event list
wp transient delete --all
wp core check-update --force

wp transient delete --all komutu güncelleme bilgisini tutan geçici kayıtları da temizler, böylece WordPress sürüm bilgisini yeniden sorgular. Bu, "güncelleme var diyor ama güncellemiyor" döngüsünü sık sık kırar.

Benzer Kilitler: Eklenti, Tema ve Bakım Dosyası#

Aynı mantık WordPress'in diğer takılma noktaları için de geçerlidir. Hepsinde çözüm aynı iki adımdır: geride kalan işaretleyiciyi kaldır, sonra asıl nedeni düzelt.

Bakım dosyası. Güncelleme başladıktan sonra kök dizine .maintenance yazılır. Süreç ölürse dosya kalır ve site "kısa süreliğine kapalı" ekranında donar. Silmek yeterlidir:

rm -f .maintenance
wp maintenance-mode status
wp maintenance-mode deactivate

Dosya nokta ile başladığı için FTP ve dosya yöneticilerinde varsayılan olarak görünmez; "gizli dosyaları göster" seçeneğini açmadan aramak boşunadır. Ayrıntısı .maintenance dosyası takıldı yazısında.

Yarım kalan eklenti veya tema klasörleri. Toplu güncelleme yarıda kesilirse wp-content/upgrade altında ve bazen eklenti klasörünün yanında -old ya da rastgele adlı artıklar kalır. Bunlar siteyi bozmaz ama disk ve inode yer. Güncelleme tamamlandıktan sonra temizleyebilirsiniz.

Yarım güncellenmiş bileşenler. Kilit kalktı, güncelleme geçti ama site tuhaf davranıyorsa büyük ihtimalle bir bileşen yarım kalmıştır. Önce verify-checksums çalıştırın; sorun bir eklentideyse onu silip temiz kurmak, dosyaların üzerine yazmaktan daha güvenlidir. Güncelleme sonrası bozulan bir sitede izlenecek sıra için güncelleme sonrası site bozuldu yazısına bakın.

Bir Daha Yaşamamak İçin Güncelleme Rutini#

Bu hatanın kök sebebi neredeyse her zaman "güncelleme için ayrılan kaynağın yetmemesi"dir. Birkaç alışkanlık, kilidi bir daha görmemenizi sağlar.

1. Toplu güncelleme yapmayın. Güncellemeler ekranındaki "Tümünü Seç" kutusu tek bir PHP isteğinde onlarca paketi indirip açmaya çalışır. Bellek ve süre limitine en çok bu şekilde çarpılır. Önce çekirdek, sonra eklentiler üçer beşer, en son tema.
2. Güncelleme öncesi yedek alın. Kilidi silmek zararsızdır, ama yarım kalan bir çekirdek güncellemesinden dönmenin tek yolu yedektir. Dosya ve veritabanını birlikte alın.
3. Sekmeyi kapatmayın. Güncelleme sırasında sayfayı yenilemek veya sekmeyi kapatmak, PHP sürecinin ölmesine ve kilidin kalmasına yol açan en yaygın kullanıcı hatasıdır.
4. Mümkünse WP-CLI kullanın. Komut satırından yapılan güncelleme, web sunucusu zaman aşımlarından ve tarayıcı kaynaklı kesintilerden etkilenmez. Tekrarlayan sorun yaşayan sitelerde tek başına çözümdür.
5. Disk ve inode kullanımını izleyin. Doluluk %85'i geçtiğinde uyarı alacak şekilde bir kontrol kurun; güncelleme, diskin dolduğunu en kötü anda öğrenmeniz için ideal bir iştir.

Yükseltme sırasında sık sık kaynak sınırına çarpıyorsanız sorun sitenizde değil, paketinizdedir. Clou.TR gibi sağlayıcıların paketlerinde PHP bellek ve süre limitleri panel üzerinden ayarlanabilir; limitleri güncelleme yapabilecek düzeye çekmek, her seferinde kilit silmekten çok daha kalıcı bir çözümdür.

Sıkça Sorulan Sorular#

core_updater.lock satırını silmek veritabanına zarar verir mi?#

Hayır. Bu satır kalıcı bir ayar değil, sürmekte olan bir işlemi işaretleyen geçici bir kayıttır. WordPress güncelleme başladığında yeniden oluşturur, bittiğinde kendisi siler. Silmenin tek riski, gerçekten devam eden bir güncelleme varken silip ikinci bir sürecin aynı anda başlamasıdır; bu yüzden silmeden önce güncellemenin gerçekten durduğundan emin olun ve başka bir sekmede işlem çalıştırmayın.

Kilit gerçekten 15 dakika sonra kendiliğinden kalkıyor mu?#

Evet, çekirdek güncelleyicisi için tanınan süre 15 dakikadır. WordPress yeni bir güncelleme isteği geldiğinde mevcut satırın zaman damgasına bakar; 15 dakikadan eskiyse kaydı geçersiz sayar, siler ve kilidi yeniden alır. Otomatik güncelleme kilidinde bu süre 1 saattir. Yani beklemek her zaman geçerli bir çözümdür; elle silmek sadece işi hızlandırır.

Kilidi sildim ama güncelleme yine aynı yerde takılıyor, ne yapmalıyım?#

Kilit semptomdur, arıza değildir. Tekrar oluşuyorsa güncelleme gerçekten yarıda ölüyor demektir. Sırasıyla şunlara bakın: hata kaydında ölümcül hata var mı, PHP bellek limiti 128 MB'ın altında mı, disk veya inode kotası dolu mu, dosya sahipliği web sunucusu kullanıcısıyla uyumlu mu. Bunlardan biri düzelmeden kilidi kaç kez silerseniz silin sonuç değişmez.

Bu hata ile bakım ekranında takılma aynı şey mi?#

Hayır, iki farklı mekanizmadır. Bakım ekranı kök dizindeki bir dosyadan gelir, ziyaretçilere gösterilir ve site kapalıdır. Güncelleme kilidi ise veritabanındaki bir satırdır, yalnızca yöneticiye görünür ve site normal çalışmaya devam eder. Aynı arıza ikisini birden bırakabilir; o durumda önce dosyayı silip siteyi açın, sonra kilidi kaldırıp güncellemeyi tamamlayın.

Kilit satırını silmek için eklenti kurmam gerekir mi?#

Gerekmez ve önerilmez. İşlem tek bir SQL satırı ya da tek bir WP-CLI komutudur. Bunun için eklenti kurmak, çözmeye çalıştığınız sorunu üreten güncelleme mekanizmasını yeniden çalıştırmak anlamına gelir — çoğu zaman eklentiyi kuramazsınız bile. phpMyAdmin veya kabuk erişiminiz varsa aracıya ihtiyacınız yoktur.

Güncelleme yarıda kaldıysa dosyalarım bozuldu mu?#

Bozulmuş olabilir, ama kontrol etmek kolaydır. WP-CLI'nin sağlama toplamı doğrulama komutları, çekirdek ve eklenti dosyalarını resmi kayıtlarla karşılaştırıp farklı olanları listeler. Liste boşsa dosyalarınız sağlamdır. Fark çıkan bileşeni silip temiz kurmak, eksik dosyaların üzerine yazmayı denemekten daha güvenilir bir onarım yoludur.