tmux ile uzun çalışan iş süreçleri: Oturum, log ve otomasyon

Uzun süren kurulumlar, veri işleme, yedek (backup) üretimi veya derleme süreçleri çoğu sunucuda tek oturumla çalıştırıldığında kritik bir risk taşır: bağlantı kopması. SSH bağlantısı kesilse bile işin aynı yerde devam etmesini sağlamak, hem zaman hem de hata maliyeti açısından belirleyicidir. Bu rehberde tmux (terminal multiplexer) ile uzun çalışan iş süreçlerini nasıl daha kontrollü yöneteceğinizi; oturum/ekran planlaması, log kaydı, yeniden bağlanma ve otomasyon adımlarını net komutlarla öğreneceksiniz.

tmux ne çözer: bağlantı kopsa bile iş sürer

SSH üzerinden sunucuya bağlanıp bir komutu çalıştırdığınızda süreç, bağlı olduğunuz terminal oturumuna bağlı davranır. Bağlantı koparsa kabuk oturumu sonlanır ve birçok komut da yarıda kalır.

tmux, tek bir terminal içinde birden fazla "oturum" ve "pencere" yönetir. En önemli fayda şudur: - SSH’den çıkabilirsiniz. - tmux oturumu arka planda yaşamaya devam eder. - Daha sonra tekrar bağlanıp aynı oturuma geri dönerek işi izleyebilirsiniz.

Bunu özellikle şu işlerde standartlaştırmak gerekir: - Büyük arşivleme ve sıkıştırma (tar, zip, zstd) - Veri dönüştürme (ETL) ve toplu işlemler - Derleme/CI adımları (build) - Paket güncelleme, kaynak derleme - Uzun süreli testler ve log toplama

tmux oturumları ve pencereler (window/pane) farkı

• Oturum (session): tmux’in ana çalışma alanı. Yeniden bağlandığınızda başlangıç noktası burasıdır.
• Pencere (window): Oturum içindeki ayrı komut/kabuk grubu.
• Pane: Bir pencereyi bölerek aynı anda birden fazla terminal alanı oluşturma.

Bu yapı, tek sunucuda birden fazla süreci düzenli şekilde takip etmeyi sağlar.

Uzun iş için en doğru tmux akışı: oturum oluştur → isim ver → log al

Aşağıdaki akış, uzun süren komutlarda en az karışıklıkla ilerlemenizi hedefler.

1) Yeni oturum başlatma ve isimlendirme

Önerilen yaklaşım oturum adını anlamlı tutmaktır (ör. "backup-2026-06-10", "etl-prod").

# Yeni oturum
tmux new -s backup-2026-06-10

Oturum içindeyken bir komutu çalıştırın.

2) O anki komut için log kaydı

tmux içinde log almanın iki yaygın yolu vardır: 1) Komutu çalıştırırken stdout/stderr yönlendirmek (en deterministik yöntem) 2) tmux’in yakalama (capture) ve çıktı akışından yararlanmak

Uzun işlerde 1. yöntem daha net sonuç verir.

Örnek: arşivleme + log

tar -C /var/www -czf /tmp/site.tar.gz ./site 2>&1 | tee /var/log/tmux-backup.log

Buradaki kritik noktalar: - 2>&1 hata çıktısını da aynı akışa dahil eder. - tee hem ekranda gösterir hem dosyaya yazar.

Eğer log dosyası disk alanını büyütecekse boyutu kontrol edin; log rotasyonu (logrotate) planlayın.

3) Komut bitince oturumu toparlama

Komut tamamlandığında: - İlgili pencereyi kapatın - Sonra oturumu kapatın

# Oturum içindeyken
exit
# ya da tmux client kapat

Birden fazla pencere/iş varsa oturum kapanmadan önce kontrol edin.

tmux ile yeniden bağlanma ve durum kontrolü

En sık yaşanan senaryo: sunucuya tekrar bağlandığınızda işin devam edip etmediğini hızlıca anlamak.

1) Oturumları listeleme

SSH’ye yeniden bağlandıktan sonra şu komutu çalıştırın:

tmux ls

Çıktıda oturum adı görünür. Bu sayede doğru işin hangi oturumda olduğunu bulursunuz.

2) Var olan oturuma geri dönme

tmux attach -t backup-2026-06-10

Kısayol olarak sürüm farklılıkları olabilir; -r (read-only) gibi seçenekleri kullanmayın, uzun işlemlerde tipik kullanım oturumun aktif olarak izlenmesi ve gerektiğinde kontrol edilmesidir.

3) O an hangi pencere/iş çalışıyor kontrolü

tmux içinde pencereyi yönetmek için iki pratik yaklaşım: - Windows listesini açın - Pane’lere bölerek eş zamanlı çıktı izleyin

Windows/pencere gezinmesi tmux key-bindings’e göre değişir. Yine de genel mantık aynı: - Bir işin log çıktısını bir pane’de tutun - Diğer pane’de süreç parametrelerini veya takip komutlarını çalıştırın

Örnek takip penceresi: - süreç PID’sini bulma - CPU/RAM/IO kontrolü

Örneğin ayrı pane’de şu tarz kontrol komutları işe yarar: - top - htop - vmstat 1 - iostat -xz 1

Disk yoğun işlerde iostat ile bekleme/IO darboğazını daha hızlı tespit edersiniz.

Pencere bölme ve düzen: aynı oturumda birden fazla uzun işi yönetme

Uzun iş süreçleri çoğu zaman tek komut değildir. Örneğin: - önce veriyi export et - sonra sıkıştır - ardından uzak depoya yükle - en son doğrulama checksum’u al

Bu durumda aynı oturum içinde birden fazla pencere oluşturmak işleri sadeleştirir.

Önerilen pencere yerleşimleri

• Window 1: Export (stdout/stderr log)
• Window 2: Sıkıştırma (log)
• Window 3: Yükleme (upload) + bağlantı yeniden deneme gözlemi
• Window 4: Doğrulama (checksum, dosya boyutu, kontrol)

Pane bölme ile aynı anda izleme

Bir pencereyi bölerek örneğin: - üst pane: canlı log - alt pane: kaynak izleme

Böylece "komut çalışıyor ama neden yavaş?" sorusuna tek oturumda yanıt bulursunuz.

Otomasyon: kopma sonrası işin devam ettiğini garantiye yaklaştırma

tmux uzun süreli işlerde pratik bir çözüm sunar; ancak doğru planlama ile daha güvenilir hale gelir.

1) İşin devamını kontrol etmek: süreç mantığını sağlam kurun

tmux’un asıl rolü oturumu taşımaktır. İşin kendisi şu prensiplerle daha dayanıklı olur: - İdempotent (tekrar çalıştırınca aynı sonucu üreten) adımlar kullanın. - Geçici dosyaları atomik şekilde üretin (örn. önce dosya.tmp, sonra mv). - Yükleme sonrası doğrulama (checksum) ekleyin.

2) Sistem yeniden başlatmasına karşı plan

tmux oturumu canlı tutsa bile sunucu yeniden başlatılırsa süreç yarıda kalabilir. Uzun vadeli DR (disaster recovery) planında şu yaklaşım gerekir: - Komutları daima bir iş yöneticisi mantığıyla paketleyin. - En azından sistem yeniden başlatıldıktan sonra kaldığınız yerden devam edecek bir kontrol ekleyin.

Bunun için pratik yöntemlerden biri cron ile "durum kontrol" adımıdır. Örneğin: - belirli klasörde yeni arşiv oluştuysa devam et - oluşmadıysa export tekrar dene

Not: Cron tarafında hatalı senaryoları engellemek için (ör. ortam değişkenleri, PATH farklılıkları) iş komutlarını tam yol ile çağırın.

3) Elde edilebilirlik: log dosyalarını standardize edin

Logların adlandırmasını deterministik yapın: - /var/log/tmux/{iş-adı}-{tarih}.log - stdout/stderr birlikte

Ayrıca logların disk kullanımını izleyin. Büyük arşivlerde log çok büyürse log dosyalarını sınırlandırın (ör. belirli satırdan sonra truncate eden bir yardımcı script).

tmux kullanımında sık yapılan hatalar ve net düzeltmeler

Uzun işlerde tmux kullanırken bazı sorunlar beklenir. Bunlar genellikle teknik değil, yöntem kaynaklıdır.

Hata 1: Oturum adını belirsiz bırakmak

“session1”, “test” gibi adlar 1 hafta sonra doğru oturumu bulmayı zorlaştırır. Oturum adını tarihle ve işle etiketle.

Hata 2: Log almadan sadece ekrana bakmak

Bağlantı koparsa ekranda görünen çıktı kaybolur. Uzun işlerde mutlaka dosyaya aktarım yapın.

Hata 3: Hata çıktısını ayırmak

Sadece stdout’u yönlendirmek, hataları gözden kaçırır. 2>&1 kullanarak hata akışını da loga dahil edin.

Hata 4: Disk doluluğu riskini hesaba katmamak

Süreç büyük veriler üretiyorsa geçici dosyalar ve loglar disk şişirebilir. İşi başlatmadan önce: - hedef dizinin disk boşluğunu kontrol edin - geçici dizini doğru partition’da konumlandırın

Örnek kontrol: - df -h - du -sh /tmp

Basit kontrol listesi: uzun iş başlatırken 10 dakikalık hazırlık

Aşağıdaki listeyi işin başlamasından önce uygulayın. Bu, kopma anında “iş bitmiş mi kaldı mı” sorusunu netleştirir.

• [ ] tmux oturumu başlatıldı ve anlamlı isim verildi (tmux new -s ...)
• [ ] Komut dosyaya log alacak şekilde çalıştırıldı (2>&1 | tee ...)
• [ ] İş akışı bir "export → işlem → doğrulama" mantığında kuruldu
• [ ] Aynı oturumda gerekirse kaynak izleme için ikinci pencere/pane hazırlandı
• [ ] İş bittikten sonra doğrulama adımı eklendi (checksum / dosya boyutu / listeleme)
• [ ] İleride kontrol için loglar standart dizinde tutuluyor

Sonuç: tmux’u standart bir operasyon adımı yapın

Uzun çalışan iş süreçlerinde risk, yalnızca komutun süresi değil; bağlantı kopması, izleme ihtiyacı ve hata ayıklamanın gecikmesidir. tmux ile oturumu kalıcı hale getirip log kaydını deterministik yaptığınızda, işi yeniden bağlanarak takip etmek pratik ve ölçülebilir olur. Bir sonraki uzun kurulum/backup/dönüştürme işinde yukarıdaki akışı uygulayın: önce oturumu isimlendirin, sonra stdout/stderr logunu dosyaya bağlayın ve iş bitiminde doğrulama ekleyin. Böylece “iş sürdü mü?” sorusuna tekrar tekrar aynı yöntemle cevap verirsiniz.