Odpowiedzi:
Domyślnie nie, to niedozwolone. W systemie Linux (od man 2 kill
):
Jedynymi sygnałami, które można wysłać do ID procesu 1, procesu init, są te, dla których init wyraźnie zainstalował procedury obsługi sygnałów. Ma to na celu zapewnienie, że system nie zostanie przypadkowo wyłączony.
Pid 1 (init) może zdecydować, że pozwala się zabić, w takim przypadku „zabójstwo” jest w zasadzie prośbą o wyłączenie się. Jest to jeden z możliwych sposobów realizacji halt
polecenia, chociaż nie jestem świadomy, init
że to robi.
Na komputerze Mac zabicie launchd
(jego analog analogowy) sygnałem 15 (SIGTERM) natychmiast uruchomi ponownie system, nie zawracając sobie głowy czystym zamykaniem uruchomionych programów. Zabicie go przy pomocy nie dającego się złapać sygnału 9 (SIGKILL) nic nie robi, pokazując, że kill()
semantyka Maca jest pod tym względem taka sama jak semantyka Linuksa.
W tej chwili nie mam pod ręką pudełka z Linuksem, z którym chciałbym eksperymentować, więc pytanie o to, co Linux A init
robi z SIGTERMem, będzie musiało poczekać. init
ponieważ projekty zastępcze, takie jak Upstart i Systemd, są obecnie popularne, odpowiedź może być różna.
AKTUALIZACJA : W systemie Linux init
jawnie ignoruje SIGTERM, więc nic nie robi. @jsbillings ma informacje o tym, co robią Upstart i Systemd.
init
z Segmentation fault
( SIGSEGV
sygnał), co spowoduje panikę jądra:kill -SEGV 1
Inicjalizacja SysV ignoruje sygnały SIGKILL lub SIGTERM. Jedynym sygnałem, który powoduje zmianę stanu, jest SIGPWR, o ile wiem, który planuje wyłączenie związane z zasilaniem.
Wygląda na to, że Upstart i Systemd również nie reagują na SIGKILL, a z mojego testu wynika, że SIGTERM powoduje ponowne uruchomienie i systemd ponownie.
Nie jestem pewien, co robią inni odpowiadający, ale jestem prawie pewien, że nie możesz zabić -9 (SIGKILL) lub zabić -15 (SIGTERM) init (pid 1). Najprawdopodobniej, gdybyś mógł, dostaniesz panikę jądra, ponieważ init nieoczekiwanie zakończył pracę z niezerowym kodem wyjścia, co byłoby mniej niż idealne. Nie wyłącza komputera ani nie powoduje jego ponownego uruchomienia.
Technicznie tak, root może wydać SIGKILL do init. init jednak różni się od większości, prawie wszystkich innych procesów, tym, że dozwolone jest wychwytywanie i ignorowanie sygnału.
Możesz, luźno, zabić init, wydając kill -TERM 1
analogiczny do wydania a halt
lub shutdown
w tym init przekaże sygnał wszystkim dzieciom, zasadniczo wszystkim innym procesom, zanim uhonoruje sam sygnał.
Uwaga: wykonanie tego polecenia spowoduje zamknięcie systemu.
Dla smaku; jednym rodzajem innego procesu, który może „zignorować” SIGKILL, jest nieprzerwany sen, taki jak czekanie na we / wy. Taki proces można znaleźć, wydając ps axo stat,comm
procesy, w których procesy o statusie „D” są nieprzerwane.
kill -TERM 1
nic nie zrobię, ale spowoduje, że init zrestartuje się na większości systemów Linux, i że jedyną rzeczą, którą możesz zrobić, aby system zamknął twój system, jest uruchomieniekill -PWR 1
kill -TERM 1
zdecydowanie powoduje ponowne uruchomienie komputera (faktycznie przechodzę przez ::shutdown:
wpis i powiązany skrypt w inittab.)
Możesz ponownie uruchomić init
proces. Jest to przydatne do wprowadzania zmian inittab
bez konieczności ponownego uruchamiania.
kill -HUP 1
Źródło: http://www.cyberciti.biz/faq/linux-unix-kill-hup-1-reread-etcinittab-file/
init
wiem, że ten sygnał nie powoduje ponownego uruchomienia procesu, a jedynie ponowne załadowanie /etc/inittab
pliku. --- Przeciwnie, systemctl daemon-reexec
naprawdę sprawia, że systemd
( init
zamiennik w systemie Linux), aby wykonać ponownie.
Cóż, root może zabić proces inicjowania w systemie Linux:
strace -p 1 -o OUT &
kill -9 1
Detale:
kill -9 1
nie działa:
-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
Więc uruchommy 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]
SIGKILL
do PID1
od github.com/torvalds/linux/commit/... została połączona.
Wpisz sudo kill -INT 1
, a następnie zobacz, co się stanie.