Bash’te Hata Yönetimi: set -euo pipefail ile Güvenli Script Yazımı
Hepimiz oradaydık: Gece yarısı gelen bir PagerDuty alarmı, çöken bir production sunucusu ve kaynağı belirsiz, yarıda kesilmiş bir deploy süreci. Loglara baktığınızda ise “exit 0” ile başarıyla tamamlanmış görünen ama arkasında enkaz bırakmış bir script görüyorsunuz. Modern devops ve altyapı otomasyonu dünyasında, linux üzerinde koşan bash scripting süreçleri hala sistemlerin can damarıdır. Ancak Kubernetes manifestleri veya Terraform kodları yazarken gösterdiğimiz özeni, maalesef bu kabuk script’lerine göstermiyoruz. “Çalışıyorsa dokunma” felsefesi, ilk production kazasına kadar kulağa hoş gelir.
Bu yazıda, Bash script’lerinizi “çocuk oyuncağı” olmaktan çıkarıp, kurumsal seviyede hata toleranslı ve güvenli hale getirecek teknikleri ele alacağız. Sadece komutları sıralamayacağız; arkasındaki “neden” sorusuna yanıt arayacağız.
Sessiz Katilleri Durdurun: set -euo pipefail
Bash’in varsayılan davranışı inanılmaz derecede affedicidir. Bir satır hata verse bile, script bir sonraki satırdan neşeyle çalışmaya devam eder. Bu durum, otomasyon süreçlerinde tam bir felaket senaryosudur. Bu vurdumduymazlığı engellemenin yolu, script’in en başına o sihirli satırı eklemektir:
#!/usr/bin/env bash
set -euo pipefailPeki bu parametreler tam olarak ne işe yarıyor? Tek tek inceleyelim ve neden hayati olduklarını görelim.
1. set -e (Exit on Error)
Varsayılan olarak Bash, sıfırdan farklı (non-zero) bir exit code ile dönen komutları önemsemez. Örneğin, veritabanı yedeği almaya çalışan bir script düşünün:
pg_dump -U admin mydb > backup.sql
tar -czf backup.tar.gz backup.sql
aws s3 cp backup.tar.gz s3://my-bucket/Eğer pg_dump komutu yetki hatasından dolayı başarısız olursa, script durmaz. Boş bir backup.sql dosyasını sıkıştırır ve S3’e yükler. Pipeline’ınız yeşil yanar ama elinizde yedek yoktur! set -e (veya uzun adıyla set -o errexit), herhangi bir komut başarısız olduğunda script’in anında sonlanmasını sağlar.
2. set -u (Nounset / Unset Variables)
Bash’te tanımlanmamış bir environment variable kullanmaya çalışırsanız, Bash bunu sessizce boş bir string olarak kabul eder. Şu meşhur felaket senaryosuna bakalım:
TARGET_DIR="" # Bir hata sonucu boş kaldı
rm -rf "$TARGET_DIR/*"Eğer set -u (veya set -o nounset) aktif değilse, bu komut rm -rf /* olarak çalışacak ve sisteminizi silecektir. Bu parametre açık olduğunda, tanımlanmamış bir değişken kullanıldığı anda Bash çalışmayı durdurur ve unbound variable hatası verir.
3. set -o pipefail
İşte en çok gözden kaçan parametre. set -e tek başına pipeline (boru hattı) kullanan komutlardaki hataları yakalayamaz. Örneğin:
non_existent_command | grep "foo"Burada ilk komut hata verecektir (exit code 127). Ancak pipeline’ın toplam exit code’u, en son komutun (yani grep’in) exit code’udur. Grep başarıyla çalıştığı için (veya eşleşme bulamadığı için) tüm satır başarılı kabul edilir. set -o pipefail eklediğimizde, pipeline içindeki herhangi bir komut hata verirse, tüm zincir başarısız kabul edilir.
Geri Temizlik (Cleanup) ve Trap Mekanizması
Script’imiz hata aldığında veya yarıda kesildiğinde (örneğin kullanıcı Ctrl+C yaptığında), arkasında geçici dosyalar, kilit (lock) dosyaları veya açık portlar bırakabilir. Linux dünyasında bu durum “resource leak” olarak adlandırılır. Bash’in sunduğu trap mekanizması, script nasıl sonlanırsa sonlansın (ister başarıyla, ister hata ile) çalışacak temizlik rutinleri yazmamızı sağlar.
Aşağıdaki örneği inceleyelim:
#!/usr/bin/env bash
set -euo pipefail
# Geçici bir dosya oluşturalım
TEMP_FILE=$(mktemp /tmp/api_response.XXXXXX)
# Temizlik fonksiyonu
cleanup() {
echo "⚙️ Temizlik yapılıyor: ${TEMP_FILE} siliniyor..."
rm -f "$TEMP_FILE"
}
# EXIT sinyalini yakala ve cleanup fonksiyonunu çalıştır
trap cleanup EXIT
# Script ana gövdesi
echo "Veri çekiliyor..."
curl -s https://api.kertenkerem.net/status > "$TEMP_FILE"
# Eğer burada bir hata olursa bile, trap sayesinde cleanup çalışacaktır.
grep -q "SUCCESS" "$TEMP_FILE"
echo "İşlem başarıyla tamamlandı."Burada trap cleanup EXIT tanımı sayesinde, script normal bir şekilde bittiğinde veya aradaki bir komut hata verip script’i sonlandırdığında cleanup fonksiyonu otomatik olarak tetiklenir.
Hata Detaylarını Yakalamak: ERR Sinyali
Sadece temizlik yapmak yetmez, bazen hatanın hangi satırda ve hangi fonksiyon içinde gerçekleştiğini loglamak isteriz. Bunun için ERR sinyalini yakalayabiliriz:
failure_handler() {
local exit_code=$?
local line_no=$1
echo "❌ HATA: Script ${line_no}. satırda, exit code ${exit_code} ile çöktü!" >&2
# Buraya Slack/Teams webhook entegrasyonu eklenebilir.
}
trap 'failure_handler ${LINENO}' ERRExit Code Standartları
Yazdığınız script’lerin birer “iyi vatandaş” olması gerekir. Yani başka bir program (örneğin Jenkins, GitHub Actions veya GitLab CI) sizin script’inizi çağırdığında, neyin yanlış gittiğini sadece loglardan değil, exit code’dan da anlayabilmelidir.
Her zaman sadece exit 1 kullanmak tembelliktir. POSIX standartlarına göre bazı exit code’ların özel anlamları vardır:
- 0: Başarılı sonlanma.
- 1: Genel bilinmeyen hatalar.
- 2: Hatalı argüman veya CLI parametresi kullanımı (Misuse of shell builtins).
- 126: Komut çalıştırılamadı (Permission denied / Not executable).
- 127: Komut bulunamadı (Command not found).
- 128+n: Fatal error signal “n” (Örn: Ctrl+C ile sonlandırma için 130).
Kendi script’lerinizde özel hata durumları için 64-113 arasındaki değerleri kullanabilirsiniz. Örneğin:
readonly ERR_DB_CONNECTION=74
readonly ERR_INVALID_CONFIG=78
if ! ping -c 1 "$DB_HOST" &> /dev/null; then
echo "Veritabanına erişilemiyor!" >&2
exit "$ERR_DB_CONNECTION"
fiBash Script Test Edilir mi? Karşınızda: Bats (Bash Automated Testing System)
“Script’i yazdım, bir kere manuel çalıştırdım, çalışıyor” mantığı modern DevOps pratiklerine aykırıdır. Altyapı kodunuz değiştikçe, yazdığınız script’lerin de test edilmesi gerekir. Bunun için en popüler framework Bats-core‘dur.
Bats, script’lerinizi gerçek assertion’lar ile test etmenizi sağlayan TAP (Test Anything Protocol) uyumlu bir test aracıdır.
Örnek Bir Bats Testi
Öncelikle test etmek istediğimiz küçük bir fonksiyonumuz olsun (helper.sh):
# helper.sh
is_semver() {
local version=$1
if [[ $version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
return 0
else
return 1
fi
}Şimdi bu fonksiyon için yazacağımız test dosyası (helper.bats):
# helper.bats
setup() {
source ./helper.sh
}
@test "Geçerli semver formatını doğrula" {
run is_semver "1.2.3"
[ "$status" -eq 0 ]
}
@test "Geçersiz semver formatını reddet" {
run is_semver "v1.2"
[ "$status" -eq 1 ]
}CI/CD pipeline’ınızda bats helper.bats komutunu çalıştırarak bu testleri otomatik hale getirebilirsiniz. Böylece birisi script’i refactor ettiğinde bir şeylerin kırılıp kırılmadığını anında görebilirsiniz.
Özet: Kurşun Geçirmez Bir Bash Şablonu
Tüm bu öğrendiklerimizi bir araya getiren, yeni projelerinizde doğrudan kopyalayıp kullanabileceğiniz güvenli bir Bash şablonu ile yazıyı sonlandıralım:
#!/usr/bin/env bash
# Güvenlik flag'leri
set -euo pipefail
IFS=$'\n\t'
# Script dizinini bul (Path bağımsız çalışabilmek için)
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# Global Hata Yakalama
error_handler() {
local exit_code=$?
local line_no=$1
echo "❌ Hata oluştu! Satır: ${line_no} | Exit Code: ${exit_code}" >&2
cleanup
exit "$exit_code"
}
cleanup() {
echo "🧹 Geçici kaynaklar temizleniyor..."
# Temizlik komutları buraya
}
# Sinyalleri dinle
trap 'error_handler ${LINENO}' ERR
trap cleanup EXIT
# Ana Kod
main() {
echo "🚀 Script başlatılıyor, dizin: ${SCRIPT_DIR}"
# Uygulama mantığınız buraya gelecek
}
main "$@"Bash scripting, doğru yapılandırılmadığında production ortamlarında saatli bir bombaya dönüşebilir. Ancak yukarıdaki pratikleri benimseyerek, kodunuzun öngörülebilir, test edilebilir ve en önemlisi güvenli olmasını sağlayabilirsiniz.