Linux’ta kill komutu bir süreci doğrudan “öldürmekten” çok, belirtilen PID’ye bir sinyal gönderir. Güvenli akış; hedef PID’yi kesin olarak bulmak, komutunu doğrulamak, önce SIGTERM göndermek, sürece kapanması için süre tanımak ve yalnızca kapanamıyorsa SIGKILL kullanmaktır.
PID nedir?
PID (Process ID), çalışan bir sürecin sayısal kimliğidir. Aynı uygulamanın birden fazla örneği farklı PID’lerle çalışabilir; ayrıca bir süreç kapandıktan sonra PID daha sonra başka bir sürece verilebilir. Bu nedenle eski bir nottaki PID’yi kullanmak yerine işlemden hemen önce hedefi yeniden doğrulamak önemlidir.
Süreçleri genel olarak incelemek için:
ps aux
top
Belirli bir süreç adını tam eşleşmeyle bulmak için pgrep -x, PID ile birlikte komut satırını görmek için de -a kullanılabilir:
pgrep -a -x firefox
Uzun süreç adları veya yorumlayıcı üzerinden çalışan betikler için ad alanı yeterli olmayabilir. Böyle bir durumda pgrep -a -f tam komut satırında arama yapar; ancak daha geniş eşleşebileceği için sonucu mutlaka inceleyin.
Güvenli sonlandırma adımları
Aşağıdaki örneklerde 1234, doğruladığınız gerçek PID ile değiştirilmelidir.
1. Süreci bulun
pgrep -a -x my-app
Tek bir sonuç beklerken birden fazla PID görürseniz hepsine sinyal göndermeyin. Önce hangi örneğin hedef olduğunu belirleyin.
2. PID’nin çalıştırdığı komutu doğrulayın
ps -p 1234 -o pid,ppid,user,stat,etime,cmd
Çıktıda PID, üst süreç, kullanıcı, durum, çalışma süresi ve komut satırı birlikte görünür. Yanlış kullanıcıya veya benzer adlı başka bir servise ait süreci durdurma riskini bu adım azaltır.
3. Önce SIGTERM gönderin
kill sinyal belirtilmediğinde varsayılan olarak SIGTERM gönderir:
kill --signal TERM 1234
SIGTERM, uygulamaya kapanış işleyicisini çalıştırma fırsatı verir. Uygulama yeni istek almayı durdurabilir, açık dosyaları kapatabilir ve tamponlanmış veriyi yazabilir. Bu davranış uygulamanın sinyali nasıl ele aldığına bağlıdır; sinyalin “nazik” olması sürecin mutlaka kapanacağı anlamına gelmez.
4. Bekleyin ve durumu yeniden kontrol edin
Uygulamaya uygun bir süre tanıdıktan sonra aynı PID’yi kontrol edin:
ps -p 1234 -o pid,stat,etime,cmd
Komut başlık dışında sonuç döndürmüyorsa süreç artık yoktur. Uzun kapanış yapan veritabanı veya worker süreçlerinde bekleme süresini uygulamanın dokümantasyonuna göre seçin.
5. Yalnızca gerekirse SIGKILL kullanın
Süreç SIGTERM sonrasında kapanmıyor ve başka bir güvenli kurtarma yolu bulunmuyorsa:
kill --signal KILL 1234
SIGKILL yakalanamaz, engellenemez veya yok sayılamaz. Uygulama temizleme kodunu çalıştıramadan çekirdek tarafından sonlandırılır; tamponlanmış durum, yarım yazılmış dosya veya tamamlanmamış işlem kaybı oluşabilir. Bu yüzden ilk adım değil, son çaredir.
Bir portu dinleyen süreci bulma
Örneğin TCP 8080 portunu dinleyen süreci ve PID bilgisini görmek için:
sudo ss -lptn 'sport = :8080'
Alternatif olarak lsof kuruluysa:
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
Bulduğunuz PID’yi yine ps ile doğruladıktan sonra aynı SIGTERM → bekle → gerekirse SIGKILL sırasını izleyin.
Sık kullanılan sinyaller
- SIGTERM (15): Varsayılan sonlandırma isteğidir; süreç bunu yakalayabilir veya yok sayabilir.
- SIGKILL (9): Süreci çekirdek seviyesinde sonlandırır; yakalanamaz, engellenemez veya yok sayılamaz.
- SIGHUP (1): Varsayılan davranışı sonlandırmadır. Bazı daemon’lar bunu yapılandırma yenileme olarak yorumlar, fakat bu evrensel değildir; uygulamanın belgesini kontrol edin.
- SIGSTOP: Süreci duraklatır ve
SIGKILLgibi yakalanamaz veya yok sayılamaz. - SIGCONT: Durmuş bir sürecin çalışmaya devam etmesini sağlar.
Numaralar bazı mimarilerde farklılaşabildiği için betiklerde kill -TERM veya kill --signal TERM gibi sinyal adları daha okunaklıdır.
İsimle sonlandırma neden dikkat ister?
pkill bir desene uyan birden fazla sürece sinyal gönderebilir. İsimle işlem yapmak zorundaysanız önce aynı eşleşmeyi yalnızca listelemek için kullanın:
pgrep -a -x my-app
Sonuç hedeflediğiniz süreçlerle birebir uyuşuyorsa yine de PID’leri tek tek incelemek en güvenli yöntemdir. Komut ikamesiyle kill -9 $(pidof ...) çalıştırmak, beklenmedik sayıda PID’yi doğrulama fırsatı olmadan hedefleyebilir; bu nedenle operasyonel örneklerde kullanılmamalıdır.
Yetki hataları ve servis yöneticileri
Bir kullanıcı normalde yalnızca yetkili olduğu süreçlere sinyal gönderebilir. sudo kullanmadan önce hedef PID’nin gerçekten doğru olduğunu iki kez kontrol edin. Süreç systemd tarafından yönetiliyorsa PID’ye doğrudan sinyal göndermek yerine çoğunlukla servis yöneticisini kullanmak daha doğrudur:
sudo systemctl stop my-app.service
Bu yaklaşım servisin tanımlı kapanış süresini, yeniden başlatma politikasını ve bağlı süreç grubunu dikkate alır.
Zombie süreçler
ps çıktısındaki STAT alanında Z görünen zombie süreç zaten çalışmasını tamamlamıştır; ona ek sinyal göndermek çıkış kaydını ortadan kaldırmaz. Üst sürecin çocuğun durumunu wait ailesiyle toplaması gerekir. Sorun tekrarlanıyorsa üst uygulamanın çocuk süreç yönetimi düzeltilmelidir; üst süreci rastgele sonlandırmak genel bir çözüm değildir.