Mailcow “Connection to Redis failed – Host is unreachable” Hatası Nasıl Çözülür?

Mailcow üzerinde zaman zaman şu hata ile karşılaşılabilir:

Connection to Redis failed.

The following error was reported:
Host is unreachable

İlk bakışta bu hata Redis servisinin çalışmadığını düşündürür. Ancak her zaman sorun Redis değildir. Özellikle Docker üzerinde çalışan Mailcow sistemlerinde bu hata; Docker ağı, container runtime, DNS veya alttaki Linux dosya sistemi arızalarının bir sonucu olabilir.

Bu rehberde gerçek bir Mailcow sunucusunda karşılaşılan Redis bağlantı hatasının nasıl teşhis edildiğini ve asıl problemin EXT4 dosya sistemi bozulması olduğunun nasıl tespit edilip onarıldığını adım adım ele alıyoruz.

---

1. İlk Kontrol: Mailcow Container Durumları

Öncelikle Mailcow dizinine geçilir:

cd /opt/mailcow-dockerized

Ardından tüm container’lar kontrol edilir:

docker compose ps

Örnek durumda Redis container’ı çalışıyor görünüyordu:

mailcowdockerized-redis-mailcow-1
redis:7.4.6-alpine
Up 5 days
127.0.0.1:7654->6379/tcp

Ancak aynı sistemde:

clamd-mailcow      unhealthy
unbound-mailcow    unhealthy

durumları da bulunuyordu.

Bu önemli bir ipucudur.

Eğer yalnızca Redis problemli olsaydı, yalnızca Redis kaynaklı bir sorun beklenebilirdi. Ancak birden fazla container’da bozulma varsa alttaki Docker veya sistem katmanı kontrol edilmelidir.

---

2. Redis Bağlantısını Test Etme

Redis’in kendisini test etmek için normalde şu komut kullanılır:

docker compose exec redis-mailcow redis-cli PING

Beklenen çıktı:

PONG

PHP-FPM container’ından Redis’e isim çözümlemesini kontrol etmek için:

docker compose exec php-fpm-mailcow getent hosts redis-mailcow

Ağ erişimini test etmek için:

docker compose exec php-fpm-mailcow ping -c 3 redis-mailcow

Ancak problemli sistemde bu testler sırasında çok daha önemli bir hata ortaya çıktı:

failed to create runc console socket:
mkdir /tmp/pty3429788895: read-only file system

Bu noktadan sonra sorun Redis olmaktan çıktı.

---

3. “Read-only file system” Ne Anlama Gelir?

Şu hata:

read-only file system

Linux’un ilgili dosya sistemine yazamadığını gösterir.

Docker ve containerd, container işlemleri sırasında sürekli olarak aşağıdaki alanlara yazma yapar:

/tmp
/var/lib/docker
/var/lib/containerd

Eğer bu alanlara yazılamıyorsa:

• Docker exec çalışmayabilir
• Redis container erişimi bozulabilir
• DNS sorguları timeout olabilir
• Container’lar unhealthy olabilir
• Loglar yazılamaz
• Mailcow web arayüzü hata verebilir

Bu nedenle önce host sistemin yazılabilir olup olmadığı kontrol edilmelidir.

---

4. Root Filesystem Mount Durumunu Kontrol Etme

Şu komutlar çalıştırılır:

mount | grep ' on / '

ve:

findmnt /

Örnekte sistem şu şekilde görünüyordu:

/dev/mapper/ubuntu--vg-ubuntu--lv on / type ext4 (rw,relatime)

İlk bakışta bu çıktı root filesystem’in yazılabilir olduğunu gösteriyor:

rw

Ancak yalnızca mount çıktısına güvenmek yeterli değildir.

Gerçek yazma testi yapılmalıdır.

---

5. Gerçek Yazma Testleri

Şu komutlar çalıştırılır:

touch /root/write-test

touch /var/write-test

touch /tmp/write-test

touch /var/lib/containerd/write-test

Problemli sistemde hepsi şu hatayı verdi:

Read-only file system

Bu durumda filesystem mount çıktısında rw görünse bile kernel seviyesinde yazma engellenmiş demektir.

---

6. Disk Doluluk ve Inode Kontrolü

Disk doluluğu kontrol edilir:

df -h

Inode durumu:

df -i

Örnekte:

Filesystem                          Size  Used Avail Use%
/dev/mapper/ubuntu--vg-ubuntu--lv    97G   85G  7.2G  93%

Inode tarafı ise:

IUse% 8%

Disk %93 doluydu ancak inode problemi yoktu.

Bu seviyede disk doluluğu problem yaratabilir fakat tek başına read-only filesystem hatasını açıklamaz.

Bu nedenle kernel loglarının incelenmesi gerekir.

---

7. Asıl Problemi Bulan Komut: dmesg

En kritik teşhis komutu:

dmesg -T | grep -Ei 'EXT4|I/O error|Buffer I/O|read-only|readonly|remount|abort|nvme|ata|blk_update'

Problemli sistemde şu kayıtlar görüldü:

EXT4-fs error (device dm-0):
Detected aborted journal

ve:

EXT4-fs (dm-0):
Remounting filesystem read-only

Ayrıca:

Journal has aborted

hataları bulunuyordu.

Bu noktada problem kesinleşti.

Mailcow Redis sorununun ana nedeni:

EXT4 dosya sisteminin journal yapısının bozulmasıydı.

Kernel filesystem’i korumak amacıyla otomatik olarak read-only moda almıştı.

---

8. EXT4 “Aborted Journal” Nedir?

EXT4 dosya sistemi metadata işlemlerinde journal mekanizması kullanır.

Örneğin:

• inode oluşturma
• dosya silme
• metadata güncelleme
• dizin değişiklikleri
• blok tahsisi

journal üzerinden yürütülür.

Journal bozulduğunda Linux veri kaybını artırmamak için filesystem’i koruma moduna alabilir.

Bu durumda loglarda genellikle şunlar görülür:

Detected aborted journal

Journal has aborted

Remounting filesystem read-only

Sonuç olarak filesystem üzerinde yazma yapan servisler çalışamaz.

Mailcow gibi Docker ağırlıklı sistemlerde bunun etkisi çok hızlı şekilde görülür.

---

9. Sunucu Disk Yapısını Kontrol Etme

Önce disk yapısı öğrenilmelidir:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS,MODEL

Örnek yapı:

sda                         200G
├─sda1                        1M
├─sda2                        2G ext4        /boot
└─sda3                      198G LVM2_member
  └─ubuntu--vg-ubuntu--lv    99G ext4        /

Bu yapıda root filesystem:

/dev/mapper/ubuntu--vg-ubuntu--lv

üzerindedir.

Sunucu bir Proxmox VM’i üzerinde çalışmaktadır ve sanal disk:

QEMU HARDDISK

olarak görünmektedir.

---

10. Çalışan Root Filesystem Üzerinde fsck Yapmayın

Root filesystem hâlâ / olarak bağlıyken şu komutu çalıştırmak doğru değildir:

fsck /dev/mapper/ubuntu--vg-ubuntu--lv

veya:

e2fsck -f /dev/mapper/ubuntu--vg-ubuntu--lv

Çünkü aktif olarak mount edilmiş filesystem üzerinde fsck çalıştırmak veri bütünlüğü açısından risklidir.

Root filesystem onarımı için sistemin normal işletim sistemi dışından veya boot aşamasındaki initramfs/recovery ortamından çalıştırılması gerekir.

---

11. Sistemi Recovery / Initramfs Modunda Açma

Sunucu kontrollü olarak kapatılır:

shutdown -h now

Proxmox konsolundan VM tekrar başlatılır.

Eğer EXT4 bozulması ciddi ise sistem zaten otomatik olarak initramfs shell’e düşebilir.

Örneğin şu mesaj görülebilir:

UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

ve:

The root filesystem on
/dev/mapper/ubuntu--vg-ubuntu--lv
requires a manual fsck

Ardından:

(initramfs)

prompt’u gelir.

Bu aslında onarım için doğru ortamdır.

---

12. Manuel fsck Çalıştırma

Initramfs ortamında şu komut çalıştırılır:

fsck -f /dev/mapper/ubuntu--vg-ubuntu--lv

Sistem çeşitli hatalar bulabilir.

Örneğin:

Inodes that were part of a corrupted orphan linked list found.
Fix<y>?

Bu durumda:

y

yazılır.

Benzer şekilde:

Clear<y>?

Reconnect<y>?

Fix<y>?

soruları gelebilir.

Onarım yapılacaksa bunlara genellikle:

y

cevabı verilir.

---

13. Örnek Gerçek fsck Hataları

Gerçek senaryoda şu tip kayıtlar görüldü:

Inodes that were part of a corrupted orphan linked list found.

ve:

Inode 1310954 was part of the orphaned inode list. FIXED.

ayrıca:

Deleted inode 2398820 has zero dtime. Fix<y>?

Bu tip hatalar EXT4 metadata yapısında tutarsızlık olduğunu gösterir.

---

14. Otomatik Onarım Seçeneği

Her soruya tek tek y vermek yerine otomatik onarım yapmak için:

fsck -fy /dev/mapper/ubuntu--vg-ubuntu--lv

kullanılabilir.

Burada:

-f

zorunlu kontrol anlamına gelir.

-y

ise tüm onarım sorularına otomatik yes cevabı verir.

Üretim sistemlerinde ilk çalıştırmada manuel kontrol tercih edilebilir.

---

15. fsck İşlemini İki Kez Çalıştırın

İlk fsck sonrasında:

FILE SYSTEM WAS MODIFIED

benzeri bir çıktı alınabilir.

Bu durumda sistemi hemen başlatmak yerine bir kez daha kontrol etmek faydalıdır:

fsck -f /dev/mapper/ubuntu--vg-ubuntu--lv

İkinci kontrolde mümkünse filesystem temiz görünmelidir.

Amaç, yeni hata bulunmaması veya aşağıdakine benzer bir sonuç almaktır:

clean

---

16. Sistemi Yeniden Başlatma

Filesystem temizlendikten sonra:

reboot

komutu ile sistem yeniden başlatılır.

Bazı initramfs ortamlarında:

exit

komutu ile normal boot işlemine devam etmek de mümkündür.

---

17. Sistem Açıldıktan Sonra İlk Kontroller

Sunucu açıldıktan sonra önce Mailcow değil filesystem kontrol edilmelidir.

Yazma testi:

touch /tmp/test-after-fsck

ve:

touch /root/test-after-fsck

Hata alınmamalıdır.

Root filesystem durumu:

findmnt /

Beklenen:

rw

Kernel logları:

dmesg -T | grep -Ei 'EXT4|I/O error|read-only|aborted journal' | tail -50

Yeni EXT4 hatası oluşmamalıdır.

---

18. Mailcow Container Kontrolü

Filesystem sağlıklıysa Mailcow kontrol edilir:

cd /opt/mailcow-dockerized

docker compose ps

Redis testi:

docker compose exec redis-mailcow redis-cli PING

Beklenen:

PONG

PHP-FPM tarafından Redis çözümlemesi:

docker compose exec php-fpm-mailcow getent hosts redis-mailcow

Ağ testi:

docker compose exec php-fpm-mailcow ping -c 3 redis-mailcow

---

19. Unbound ve ClamAV Durumunu da Kontrol Edin

İlk hata sırasında:

clamd-mailcow      unhealthy
unbound-mailcow    unhealthy

durumu bulunuyordu.

Filesystem düzeldikten sonra:

docker compose ps

ile tekrar kontrol edilmelidir.

Gerekirse:

docker compose logs --tail=100 unbound-mailcow

ve:

docker compose logs --tail=100 clamd-mailcow

incelenebilir.

---

20. Docker ve Containerd Kontrolü

Docker:

systemctl status docker

Containerd:

systemctl status containerd

Loglar:

journalctl -u docker -n 100 --no-pager

journalctl -u containerd -n 100 --no-pager

Özellikle şu tarz kayıtların tekrar oluşmadığından emin olunmalıdır:

read-only file system

---

21. Disk Doluluğu Problemini İhmal Etmeyin

Filesystem düzeldikten sonra ikinci önemli problem disk doluluğudur.

Örnekte root LV:

97 GB

ve kullanım:

85 GB
%93

seviyesindeydi.

Ancak VM’in sanal diski:

200 GB

idi.

LVM tarafında root LV yalnızca yaklaşık:

99 GB

olarak ayrılmıştı.

Bu durumda Volume Group içinde kullanılmayan alan bulunabilir.

Kontrol için:

pvs

vgs

lvs

kullanılır.

Eğer VG içinde boş alan varsa root filesystem genişletilebilir.

Örneğin:

lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

ve ardından:

resize2fs /dev/ubuntu-vg/ubuntu-lv

ile filesystem genişletilebilir.

Bu işlemden önce mutlaka:

vgs
lvs
pvs

çıktıları kontrol edilmelidir.

---

22. Bu Hatanın Muhtemel Ana Sebepleri

EXT4 journal bozulmasının altında farklı nedenler olabilir:

• Ani elektrik kesintisi
• VM’in sert şekilde kapatılması
• Hypervisor reset
• Storage bağlantısının kısa süreli kopması
• Fiziksel disk arızası
• SAN/NAS problemi
• RAID problemi
• Kernel veya storage driver problemi
• Diskin tamamen dolması
• Host node çökmesi
• QEMU I/O problemi

Bu nedenle yalnızca fsck yapmak yeterli değildir.

Asıl sebep ayrıca araştırılmalıdır.

---

23. Proxmox Tarafında Yapılması Gereken Kontroller

VM Proxmox üzerinde çalışıyorsa node tarafında şu loglar kontrol edilmelidir:

dmesg -T | grep -Ei 'I/O|error|disk|nvme|ata|reset'

journalctl -k

Storage durumu:

pvesm status

Disk sağlık durumu fiziksel storage yapısına göre ayrıca kontrol edilmelidir.

Eğer ZFS kullanılıyorsa:

zpool status

Eğer RAID controller varsa ilgili controller logları incelenmelidir.

---

24. Önemli Uyarılar

Filesystem read-only moda geçmişken şu işlemlerden kaçının:

docker system prune

docker compose down

docker compose pull

apt upgrade

mount -o remount,rw /

Özellikle journal bozukken filesystem’i zorla tekrar rw moda almak veri bozulmasını artırabilir.

Önce:

fsck

ile filesystem tutarlılığı onarılmalıdır.

---

Sonuç

Mailcow üzerinde görülen:

Connection to Redis failed
Host is unreachable

hatası her zaman Redis servisinin bozuk olduğu anlamına gelmez.

Bu örnekte gerçek sorun şuydu:

EXT4 journal corruption

Kernel bunun sonucunda root filesystem’i:

read-only

moduna aldı.

Bu da zincirleme olarak:

• Redis erişim problemlerine
• Docker exec hatalarına
• Unbound DNS timeout’larına
• container health problemlerine
• journald yazma hatalarına
• Mailcow web arayüzü problemlerine

neden oldu.

Sorun aşağıdaki işlem ile çözülebilecek hale getirildi:

fsck -f /dev/mapper/ubuntu--vg-ubuntu--lv

ve filesystem üzerindeki bozuk inode/journal kayıtları düzeltildi.

Bu nedenle Mailcow veya başka bir Docker uygulamasında beklenmedik şekilde birden fazla servis aynı anda hata vermeye başlarsa yalnızca container seviyesine odaklanmamak gerekir.

Şu üç katmanı birlikte kontrol etmek en doğru yaklaşımdır:

Uygulama
   ↓
Docker / Containerd
   ↓
Linux Filesystem / Storage

Çünkü üst katmandaki bir Redis hatasının gerçek sebebi, bazen en alttaki disk veya filesystem problemi olabilir.