O root pode matar o processo init?

38

O root pode matar o processo init (o processo com o pid 1)? Quais seriam suas consequências?

root init

— Dharmit
fonte

38

Por padrão, não, isso não é permitido. No Linux (de man 2 kill):

Os únicos sinais que podem ser enviados para o ID do processo 1, o processo init, são aqueles para os quais o init instalou explicitamente manipuladores de sinal. Isso é feito para garantir que o sistema não seja desativado acidentalmente.

O Pid 1 (init) pode decidir se permitir ser morto; nesse caso, o "kill" é basicamente um pedido para que se desligue. Essa é uma maneira possível de implementar o haltcomando, embora eu não conheça ninguém initque faça isso.

Em um Mac, matar launchd(seu analógico init) com o sinal 15 (SIGTERM) reinicia imediatamente o sistema, sem se preocupar em desligar os programas em execução de forma limpa. Matá-lo com o sinal inacessível 9 (SIGKILL) não faz nada, mostrando que a kill()semântica do Mac é a mesma que a do Linux a esse respeito.

~~No momento, não tenho uma caixa do Linux à mão com a qual estou disposto a experimentar; portanto, a questão do que o Linux initfaz com o SIGTERM terá que esperar.~~ E com initprojetos de substituição como o Upstart e Systemd sendo populares hoje em dia, a resposta pode ser variável.

ATUALIZAÇÃO : No Linux, initignora explicitamente o SIGTERM, por isso não faz nada. O @jsbillings tem informações sobre o que o Upstart e o Systemd fazem.

— Jander
fonte

1

Parece que você já encontrou, mas para a posteridade: unix.stackexchange.com/questions/85364

— Jander

1

Você pode matar initcom um sinal Segmentation fault( SIGSEGV), o que resultará em pânico no kernel:kill -SEGV 1

— Johnson Steward

13

O init do SysV ignora os sinais SIGKILL ou SIGTERM. O único sinal que causa uma mudança de estado é o SIGPWR, até onde eu sei, que programa um desligamento relacionado à energia.

Parece que o Upstart e o Systemd também não respondem ao SIGKILL e, pelo meu teste, parece que um SIGTERM faz com que o Upstart e o systemd sejam reexecutados.

Não tenho certeza do que os outros atendentes estão executando, mas tenho certeza de que você não pode matar -9 (SIGKILL) ou kill -15 (SIGTERM) init (pid 1). Muito provavelmente, se você pudesse, teria um pânico no kernel porque o init saiu inesperadamente com um código de saída diferente de zero, o que seria menor que o ideal. Ele não desliga o computador ou faz com que ele seja reiniciado.

— jsbillings
fonte

6

Tecnicamente sim, o root pode emitir um SIGKILL para iniciar. O init, no entanto, difere da maioria, quase todos os outros processos, na medida em que é permitido capturar e ignorar o sinal.

Você pode, vagamente, matar o init emitindo um kill -TERM 1que seria análogo ao emitir um haltou shutdownnesse init passará o sinal para todos os filhos, essencialmente todos os outros processos, antes de honrar o próprio sinal.

Por favor, note: executar este comando vontade desligar o sistema.

Para sabor; um tipo de outro processo que pode "ignorar" um SIGKILL é aquele em suspensão ininterrupta, como um que espera por E / S. Esse processo pode ser encontrado emitindo um ps axo stat,commprocesso em que o status 'D' é ininterrupto.

— Tok
fonte

2

Na verdade, pelos meus testes, kill -TERM 1nada fará além de fazer com que o init seja reexecutado na maioria dos sistemas Linux, e a única coisa que você poderia fazer para kill -PWR 1

— interromper

@jsbillings Nos SBCs Linux embarcados com os quais estou trabalhando, kill -TERM 1definitivamente causa uma reinicialização (realmente passando pela ::shutdown:entrada e pelo script associado no inittab.)

— SF.

Se o init estiver no estado D por muito tempo, seu sistema estará realmente doente.

— 28716 Joshua

6

Você pode reiniciar o initprocesso. Isso é útil para fazer alterações inittabsem precisar reiniciar.

kill -HUP 1

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

— jonescb
fonte

1

Nas implementações de initsei que esse sinal não faz o processo reiniciar, mas apenas para recarregar o /etc/inittabarquivo. --- Contrário systemctl daemon-reexecrealmente faz systemd( initsubstituição no Linux) para re-executar.

— Pabouk

4

sudo kill -INT 1(interrupção) reiniciará o sistema e sudo kill -SEGV 1(violação de segmentação) ou sudo kill -ABRT 1(abortar) gerará um pânico no kernel.

nota: sudo é necessário.

— ComMania
fonte

2

Bem, o root pode matar o processo init no Linux:

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

Detalhes:

kill -9 1 não funciona:

-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

Então, vamos correr 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]

— Evgeny Vereshchagin
fonte

Parece que o kernel não foi entregar SIGKILLa PID1desde github.com/torvalds/linux/commit/... foi incorporada.

— Evgeny Vereshchagin

-2

Digite sudo kill -INT 1e veja o que acontece.

— Siddhartha Biswas
fonte