Ebeveyn ile <defunct> süreci öldürmek için nasıl 1


17

Bacula'yı bir RedHat kutusunda çalıştırıyorum. Zaman zaman, depolama daemon bacula-sd çalışmayı durdurur ve olur <defunct>.

[root@backup ~]# ps -ef | grep defunct | more
root      4801 29261  0 09:25 pts/5    00:00:00 grep defunct
root      5825     1  0 Oct18 ?        00:00:00 [bacula-sd] <defunct>

Sorum şu: Bu süreci nasıl öldürebilirim? Ebeveyni 1, init olduğunu bildiğim kadarıyla ve init sürecini öldürmek istemem, olur mu?

Bu işlemi 'normalde' öldürmek işe yaramıyor:

[root@backup ~]# kill -0 5825
[root@backup ~]# kill -9 5825

Yardım büyük beğeni topluyor!

Düzenle: çalışıyor

[root@backup ~]# lsof -p 5825

aşağıdaki çıktıyı üretir:

COMMAND    PID USER   FD   TYPE  DEVICE     SIZE    NODE NAME
bacula-sd 5825 root  cwd    DIR   253,0     4096 3801089 /root
bacula-sd 5825 root  rtd    DIR   253,0     4096       2 /
bacula-sd 5825 root  txt    REG   253,0  2110599  368004 /usr/local/sbin/bacula-sd
bacula-sd 5825 root  mem    REG   253,0    75284  389867 /usr/lib/libz.so.1.2.3
bacula-sd 5825 root  mem    REG   253,0    46680 3604521 /lib/libnss_files-2.5.so
bacula-sd 5825 root  mem    REG   253,0   936908  369115 /usr/lib/libstdc++.so.6.0.8
bacula-sd 5825 root  mem    REG   253,0   125736 3606807 /lib/ld-2.5.so
bacula-sd 5825 root  mem    REG   253,0  1602128 3606885 /lib/libc-2.5.so
bacula-sd 5825 root  mem    REG   253,0   208352 3606892 /lib/libm-2.5.so
bacula-sd 5825 root  mem    REG   253,0   125744 3606887 /lib/libpthread-2.5.so
bacula-sd 5825 root  mem    REG   253,0    25940 3604573 /lib/libacl.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    15972 3604535 /lib/libattr.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    46548 3606908 /lib/libgcc_s-4.1.2-20080102.so.1
bacula-sd 5825 root  mem    REG   253,0 56422480  366368 /usr/lib/locale/locale-archive
bacula-sd 5825 root    0r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    1r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    2r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    3u   CHR   9,128             6469 /dev/nst0
bacula-sd 5825 root    4u  IPv4 1023380              TCP backup:bacula-sd (LISTEN)
bacula-sd 5825 root    5u  IPv4 2693268              TCP backup:bacula-sd->backup:53957 (CLOSE_WAIT)
bacula-sd 5825 root    7u  IPv4 3248683              TCP backup:bacula-sd->backup:57629 (CLOSE_WAIT)
bacula-sd 5825 root    8u  IPv4 3250966              TCP backup:bacula-sd->backup:37650 (CLOSE_WAIT)
bacula-sd 5825 root    9u  IPv4 3253908              TCP backup:bacula-sd->backup:37671 (CLOSE_WAIT)

Yanıtlar:


18

Zombi / defunct sürecini kaldırmanın tek yolu ebeveynleri öldürmek olacaktır. Ebeveyn init olduğundan (pid 1), bu da sisteminizi devralır.

Bu sizi iki seçenekle bırakıyor.

  • İşlem tablosunu el ile değiştirin, örn. kukla bir süreç oluşturun, geçersiz süreci kukla bir çocuk olarak bağlayın, sonra onları öldürün. Oldukça tehlikeli ve semaforlar ve dosya tanıtıcıları gibi diğer işlem kaynaklarını el ile temizlemeniz gerekebilir.
  • Sistemi yeniden başlatın.

İkincisi ile giderdim.


2
+1. Bununla birlikte, daha fazla zombi işlemi görünmediği veya zombi işleminizin RAM'inizi 4G'yi kilitlemediği sürece, bunu yapmak için acele etmeyin. :)
Kyle Smith

1
"Üst öğe başlatıldığından (pid 1), bu da sisteminizi devirir" - initSIGKILL için sinyal işleyicisi olmadığından öldüremezsiniz . Bkz man 2 kill.
Cawflands

İlkini nasıl yapıyorsun?
skerit

@AndrewH SIGKILL'in hedef süreçteki bir sinyal işleyiciye bağlı olduğundan emin değilim, ancak tipik çekirdeğin SIGKILL'i başlatmak için yok sayacağı doğru. Bununla birlikte, bir çekirdek paniğini tetiklemek için daha havalı yollardan kaçarsanız, çoğu Linux sisteminde bir SIGSEGV'in oldukça iyi yapacağını düşünüyorum.
Roy

1
İşlerinden birinin initzombi süreçlerini biçmek olduğu unutulmamalıdır , bu yüzden yeterince beklerseniz initzombi süreçlerini temizlemeniz gerekir. Her ne kadar çoğu inits işleyicisi belirlesin SIGCHLDolmak SIG_IGN bu düzeltmeleri hangi.
cyphar

3

İnit'i yeniden başlatmayı deneyebilirsiniz:

 # telinit u

Aksi takdirde çok fazla endişelenmezdim. Çalışmıyor ve kaynak almıyor ve sadece orada, böylece çekirdek bunu hatırlıyor.


1
Şey, endişelenmem gerekiyor. yedekleme (bacula) ve voip (yıldız) hizmetleri çalıştıran bir üretim makinesidir. geçersiz bacula-sd işlemi olduğu sürece, bacula teyp sürücüsüne erişemiyor gibi görünmüyor ...
andreas-h

Açık dosyaları olmamalıdır. Lsof -p 5825'i çalıştırın ve kontrol edin.
David Pashley

Açık çok şey var gibi görünüyor ... yukarıya bakın. Ne yapabileceğime dair bir fikrin var mı? Ben hiç lsof kullanmadım ...
andreas-h

1
Evet, zombinin / dev / nst0 açık. Bir sistemin yeniden başlatılması muhtemelen bu noktada en iyi bahistir.
Kyle Smith

5
Evet, yeniden başlatma geçerli cevap gibi görünüyor. Bir sunucuyu yeniden başlatmam gerektiğinde hep başarısız olduğumu hissediyorum. :(
David Pashley

3

Çekirdek paniği olup olmadığını kontrol edin,

# dmesg |tail

Sürecin henüz geri dönmeyen bazı sistem çağrıları için çekirdek modunda olduğu "D" Unkillable uyku durumunda olup olmadığını kontrol edin (çekirdek oops veya başka bir nedenle) http://www.nabble.com/What-causes-an -unkillable işlem - td20645581.html


sinir bozucu biçimlendirme
asdmin

aslında herhangi bir çekirdek paniği olmadı. süreç 'Z' durumunda - bir zombi ...
andreas-h

3

Bir zombi ana öğesi olarak başlatırsa, init düzgün çalışmayı durdurdu. Init'in rollerinden biri zombi temizlemektir. Eğer yapmazsa, başkası yapmaz. Yani tek çözüm yeniden başlatmak. İnit bozulursa, yeniden başlatma başarısız olabilir, bu yüzden önemli hizmetleri kapatabilirim, dosya sistemini senkronize edip bunun yerine güç düğmesine basardım.


İnit'in düzgün çalışmamasına katılıyorum. Ayrıca bakınız: upstartve systemd.
Mikko Rantalainen

2

Paniği aşağıda tutalım, olur mu? Bir "geçersiz" veya "zombi" işlemi bir süreç değildir . Kaydedilmiş bir çıkış koduyla işlem tablosundaki bir girdidir. Bu nedenle, bir zombi kaynak tutmaz, CPU döngüleri almaz ve bellek kullanmaz, çünkü bir işlem değildir . Tüm tuhaf ve kaşıntılı zombi süreçlerini "öldürmeye" çalışmayın. Tıpkı isimleri gibi, zaten öldükleri için öldürülemezler. Ancak beyin yiyen türden farklı olarak, kesinlikle kimseye zarar vermezler ve diğer süreçleri ısırmazlar.

Zombi süreçlerinin beynini yemesine izin verme. Sadece görmezden gel.


11
Evet, teori bu. Ne yazık ki bu her zaman doğru değildir. Andreash'ın açıkça belgelediği gibi, geçersiz bir süreç bazen sistem kaynaklarına dayanacaktır.
Roy

5
Onun durumunda, her çıktıda, zombi süreci / dev / nst0'in beyinlerini yiyor. Yedekleme işlemlerine devam etmek için bu beyinlere ihtiyacı var.
Kyle Smith

2
Kariyerini Zombie süreçlerini göz ardı ederek geçiren bir sistem yöneticisi, sonunda geceleri hayatları onlardan çekilerek uyanacak. Bir Zombi, tecrübelerime göre, yanlış bir şeyin göstergesi. Bunları bir zombi çocuğunun ebeveyniyle garip bir etkileşimi olsa bile yazıyorum ve ebeveyn CPU'mu döndürüyor. Kimin suçu olduğunu bilmiyorum, ama mesele şu ki Zombiler çirkin ve onları görmezden gelmek bir gün seni rahatsız edecek. ... Bir gün ... huzurlu bir şekilde uyurken ... gecenin ortasında ... soğuk bir sonbahar gününden sonra ...
Mike S

@MikeS Yorumundan iyi bir kahkaha aldım!
Paul Calabro

@MikeS haklı. Ssh-agent defunct var ve ssh ne git düzgün çalışamaz. sadece yeniden başlatma yardımcı olabilir. (Windows ile aynı düzeltme ... haha)
John Tribe

0

Artık yetim bir sürecin var gibi görünüyor. Bildiğim kadarıyla bunları öldürmenin tek yolu kutuyu yeniden başlatmak olacaktır. Bu zaman zaman ESX sunucuları (başlık altında linux olan) oldu ve bir ana bilgisayar yeniden başlatma (VMware desteği) düzeltme.

Ben bir Windows adamıyım, bu yüzden ne için olduğunu al.


ne yazık ki, yeniden başlatma gerçek bir seçenek değil. Ayrıca voip hizmetleri çalışan bir üretim makinesi, bu yüzden çalışma saatleri içinde yeniden başlatamıyorum ...
andreas-h

1
yani çalışma saatlerinden sonra yeniden başlatabilirsiniz, değil mi?
warren
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.