Czy proces inicjowania root roota?


38

Czy proces root root kill (proces z pid 1)? Jakie byłyby tego konsekwencje?

Odpowiedzi:


38

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 haltpolecenia, 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 initrobi z SIGTERMem, będzie musiało poczekać. A initponieważ projekty zastępcze, takie jak Upstart i Systemd, są obecnie popularne, odpowiedź może być różna.

AKTUALIZACJA : W systemie Linux initjawnie ignoruje SIGTERM, więc nic nie robi. @jsbillings ma informacje o tym, co robią Upstart i Systemd.


1
Wygląda na to, że już go znalazłeś, ale dla potomności: unix.stackexchange.com/questions/85364
Jander

1
Można zabić initz Segmentation fault( SIGSEGVsygnał), co spowoduje panikę jądra:kill -SEGV 1
Johnson Steward

13

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.


6

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 1analogiczny do wydania a haltlub shutdownw 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,commprocesy, w których procesy o statusie „D” są nieprzerwane.


2
Właściwie, z moich testów, kill -TERM 1nic 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
jsbillings

@ jsbillings Na wbudowanych SBC z Linuxem, nad którymi pracuję, kill -TERM 1zdecydowanie powoduje ponowne uruchomienie komputera (faktycznie przechodzę przez ::shutdown:wpis i powiązany skrypt w inittab.)
SF.

Jeśli init jest w stanie D przez długi czas, twój system jest naprawdę chory.
Joshua

6

Możesz ponownie uruchomić initproces. Jest to przydatne do wprowadzania zmian inittabbez konieczności ponownego uruchamiania.

kill -HUP 1

Źródło: http://www.cyberciti.biz/faq/linux-unix-kill-hup-1-reread-etcinittab-file/


1
W implementacjach initwiem, że ten sygnał nie powoduje ponownego uruchomienia procesu, a jedynie ponowne załadowanie /etc/inittabpliku. --- Przeciwnie, systemctl daemon-reexecnaprawdę sprawia, że systemd( initzamiennik w systemie Linux), aby wykonać ponownie.
pabouk

4

sudo kill -INT 1(przerwanie) zrestartuje system, a sudo kill -SEGV 1(naruszenie segmentacji) lub sudo kill -ABRT 1(przerwanie) wygeneruje panikę jądra.

Uwaga: wymagane jest sudo.


2

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]

Wydaje się, że jądra nie został dostarczanie SIGKILLdo PID1od github.com/torvalds/linux/commit/... została połączona.
Evgeny Vereshchagin

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.