Kök başlangıç ​​işlemini öldürebilir mi?

Kök init sürecini öldürebilir mi (pid 1 ile işlem)? Bunun sonuçları ne olurdu?

Varsayılan olarak, hayır, buna izin verilmez. Linux altında (from man 2 kill):

ID 1 işlemine gönderilebilecek tek sinyaller, init işlemi, init için açıkça sinyal işleyicilerinin kurulu olduğu sinyallerdir. Bu, sistemin yanlışlıkla düşürülmemesini sağlamak için yapılır.

Pid 1 (init) öldürülmesine izin vermeye karar verebilir, bu durumda “öldür” temelde kendisini durdurma isteğidir. Bu, haltkomutu yerine getirmenin olası bir yoludur , ancak bunu yapanların farkında değilim init.

Mac'te, launchdsinyal 15 (SIGTERM) ile öldürme (init analogu), çalışan programları temiz bir şekilde kapatmak için zahmete girmeden sistemi hemen yeniden başlatır. Yakalanamayan sinyal 9 (SIGKILL) ile onu öldürmek hiçbir şey yapmaz, Mac'in kill()anlambiliminin bu konuda Linux ile aynı olduğunu gösterir.

Şu anda, denemek istediğim bir Linux initkutum yok , bu yüzden Linux'un bir SIGTERM ile ne yaptığı sorusu beklemek zorunda kalacak. Üstelik initUpstart ve Systemd gibi yenileme projeleri bugünlerde popüler hale geldiğinde, cevap değişken olabilir.

GÜNCELLEME : Linux'ta initSIGTERM'i açıkça görmezden geliyor, bu yüzden hiçbir şey yapmıyor. @ jsbillings, Upstart ve Systemd'nin yaptıkları hakkında bilgi içerir.

SysV init, SIGKILL veya SIGTERM sinyallerini yoksayar. Durumda bir değişikliğe neden olan tek sinyal, hangi güç ile ilgili bir kapanma planladığını söyleyebileceğim kadarıyla SIGPWR'dir.

Upstart ve Systemd'nin de SIGKILL'e yanıt vermediği anlaşılıyor ve testimden itibaren, bir SIGTERM'in start-up ve systemd'nin yeniden çalışmasına neden olduğu görülüyor.

Diğer cevaplayıcıların ne çalıştığından emin değilim ama -9 (SIGKILL) veya -15 (SIGTERM) init (pid 1) öldüremediğinizden eminim. Büyük olasılıkla, eğer başarabilseydiniz, bir çekirdek paniği elde edersiniz, çünkü başlangıçta sıfırdan farklı bir çıkış koduyla beklenmedik bir şekilde çıkılır, ki bu idealden daha az olurdu. Bilgisayarınızı kapatmaz veya yeniden başlatılmasına neden olmaz.

Teknik olarak evet, root bir SIGKILL yayınlayabilir. Bununla birlikte, init, çoğu, neredeyse hepsinden farklı olarak, sinyali yakalama ve görmezden gelmesine izin verilen diğer işlemlerden farklıdır.

Gevşek olarak, initin, kill -TERM 1a haltveya shutdowninin yayınlanmasına benzer olanı vermesi ile öldürebilirsiniz, init , sinyalin kendisini onurlandırmadan önce tüm çocuklara, özellikle de diğer tüm işlemlere sinyal iletir.

Lütfen dikkat: Bu komutu gerçekleştirmek sisteminizi durduracaktır .

Lezzet için; Bir SIGKILL'i "görmezden gelebilecek" başka bir işlem türü, g / Ç için beklemek gibi kesintisiz bir uykuda olandır. Böyle bir işlem, ps axo stat,comm'D' statüsündeki işlemlerin kesintisiz olduğu bir yere basılarak bulunabilir.

initİşlemi yeniden başlatabilirsiniz . Bu, inittabyeniden başlatmadan değişiklik yapmak için kullanışlıdır .

kill -HUP 1

Kaynak: http://www.cyberciti.biz/faq/linux-unix-kill-hup-1-reread-etcinittab-file/

sudo kill -INT 1(kesme) sistemi yeniden sudo kill -SEGV 1başlatır ve (bölümleme ihlali) veya sudo kill -ABRT 1(iptal) bir çekirdek paniği oluşturur.

not: sudo gereklidir.

Kök Linux'ta init işlemini öldürebilir:

strace -p 1 -o OUT &
kill -9 1

Detaylar:

kill -9 1 çalışmıyor:

-bash-4.3# trace-cmd start -e signal_deliver -f 'common_pid == 1' -e signal_generate -f 'pid == 1'

-bash-4.3# echo "My first attempt" >/sys/kernel/debug/tracing/trace_marker
-bash-4.3# kill -9 1

-bash-4.3# trace-cmd show # there is no signal_deliver-event
...
        bash-164   [000] .N..    29.302996: tracing_mark_write: My first attempt
        bash-164   [000] d...    29.312586: signal_generate: sig=9 errno=0 code=0 comm=systemd pid=1 grp=1 res=1

Öyleyse, koşalım strace:

-bash-4.3# echo 1 >/proc/sys/kernel/ftrace_dump_on_oops
-bash-4.3# strace -p 1 -o OUT &
[1] 179
strace: Process 1 attached
-bash-4.3# echo "My second attempt" >/sys/kernel/debug/tracing/trace_marker
-bash-4.3# kill -9 1

bash-4.3# [  134.943439] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[  134.943439]
[  134.943439] CPU: 0 PID: 1 Comm: systemd Not tainted 4.7.2-201.fc24.x86_64 #1
[  134.943439] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[  134.943439]  0000000000000086 00000000610ec632 ffff88001ea43c10 ffffffff813d941f
[  134.943439]  ffffffff81a290c0 ffff88001ea43ca8 ffff88001ea43c98 ffffffff811b2cb6
[  134.943439]  ffffffff00000010 ffff88001ea43ca8 ffff88001ea43c40 00000000610ec632
[  134.943439] Call Trace:
[  134.943439]  [<ffffffff813d941f>] dump_stack+0x63/0x84
[  134.943439]  [<ffffffff811b2cb6>] panic+0xde/0x22a
[  134.943439]  [<ffffffff810a40ac>] do_exit+0xb6c/0xb70
[  134.943439]  [<ffffffff810a4137>] do_group_exit+0x47/0xb0
[  134.943439]  [<ffffffff810af3ed>] get_signal+0x28d/0x630
[  134.943439]  [<ffffffff81025f57>] do_signal+0x37/0x6c0
[  134.943439]  [<ffffffff8100325b>] ? do_audit_syscall_entry+0x4b/0x70
[  134.943439]  [<ffffffff810ca250>] ? wake_up_q+0x70/0x70
[  134.943439]  [<ffffffff8100330c>] exit_to_usermode_loop+0x8c/0xd0
[  134.943439]  [<ffffffff81003df3>] do_syscall_64+0x103/0x110
[  134.943439]  [<ffffffff817eb921>] entry_SYSCALL64_slow_path+0x25/0x25
[  134.943439] Dumping ftrace buffer:
[  134.943439] ---------------------------------
[  134.943439]     bash-154     0.... 10592888us : tracing_mark_write: My first attempt
[  134.943439]     bash-154     0d... 17328079us : signal_generate: sig=9 errno=0 code=0 comm=systemd pid=1 grp=1 res=1
[  134.943439]     bash-154     0.... 80772500us : tracing_mark_write: My second attempt
[  134.943439]     bash-154     0dN.. 85426791us : signal_generate: sig=9 errno=0 code=0 comm=systemd pid=1 grp=1 res=0
[  134.943439]  systemd-1       0d... 85437478us : signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
[  134.943439] ---------------------------------
[  134.943439] Kernel Offset: disabled
[  134.943439] ---[ end Kernel panic - not syncing: Attempted to kill     init! exitcode=0x00000009
[  134.943439]

Yaz sudo kill -INT 1, sonra ne olacağını gör.