¿Puede root matar proceso de inicio?

38

¿Puede root matar proceso init (el proceso con pid 1)? ¿Cuáles serían sus consecuencias?

root init Dharmit
fuente

Respuestas:

38

Por defecto, no, eso no está permitido. Bajo Linux (desde man 2 kill):

Las únicas señales que pueden enviarse al ID de proceso 1, el proceso init, son aquellas para las que init ha instalado explícitamente controladores de señal. Esto se hace para asegurar que el sistema no se caiga accidentalmente.

Pid 1 (init) puede decidir dejarse matar, en cuyo caso el "kill" es básicamente una solicitud para que se cierre. Esta es una forma posible de implementar el haltcomando, aunque no conozco ninguno initque lo haga.

En una Mac, matar launchd(su análogo de inicio) con la señal 15 (SIGTERM) reiniciará inmediatamente el sistema, sin molestarse en cerrar los programas en ejecución sin problemas. Matarlo con la señal inalcanzable 9 (SIGKILL) no hace nada, lo que demuestra que la kill()semántica de Mac es la misma que la de Linux a este respecto.

Por el momento, no tengo una caja de Linux a mano con la que estoy dispuesto a experimentar, por lo que la pregunta de qué hace Linux initcon un SIGTERM tendrá que esperar. Y con initproyectos de reemplazo como Upstart y Systemd siendo populares en estos días, la respuesta podría ser variable.

ACTUALIZACIÓN : En Linux, initignora explícitamente SIGTERM, por lo que no hace nada. @jsbillings tiene información sobre lo que hacen Upstart y Systemd.

Jander
fuente
1
Parece que ya lo encontraste, pero para la posteridad: unix.stackexchange.com/questions/85364
Jander
1
Puede matar initcon una señal Segmentation fault( SIGSEGV), lo que dará como resultado un pánico en el núcleo:kill -SEGV 1
Johnson Steward
13

El init SysV ignora las señales SIGKILL o SIGTERM. La única señal que causa un cambio de estado es SIGPWR, por lo que puedo decir, que programa un apagado relacionado con la energía.

Parece que Upstart y Systemd tampoco responden a SIGKILL, y de mi prueba, parece que un SIGTERM hace que upstart y systemd se vuelvan a ejecutar.

No estoy seguro de lo que los otros respondedores están ejecutando, pero estoy bastante seguro de que no puede matar -9 (SIGKILL) o kill -15 (SIGTERM) init (pid 1). Lo más probable es que si pudiera, obtendría un kernel panic porque init salió inesperadamente con un código de salida distinto de cero, que sería menos que ideal. No apaga la computadora ni hace que se reinicie.

jsbillings
fuente
6

Técnicamente sí, root puede emitir un SIGKILL a init. init, sin embargo, difiere de la mayoría, casi de hecho, de otros procesos en que se le permite atrapar e ignorar la señal.

Puede, libremente, matar a init emitiendo un kill -TERM 1que sería análogo a emitir un halto shutdownen ese init pasará la señal a todos los niños, esencialmente todos los demás procesos, antes de honrar la señal en sí.

Tenga en cuenta: realizar este comando apagará su sistema.

Por sabor; Un tipo de otro proceso que puede "ignorar" un SIGKILL es uno en reposo ininterrumpido, como uno que espera E / S. Tal proceso podría encontrarse emitiendo un ps axo stat,commproceso donde los procesos con un estado 'D' son ininterrumpibles.

Tok
fuente
2
En realidad, a partir de mis pruebas, kill -TERM 1no hará más que causa init para sí re-ejecutivo en la mayoría de los sistemas Linux, y que la única cosa que podría hacer para causar un sistema para apagar el sistema es ejecutarkill -PWR 1
jsbillings
@jsbillings En los SBC de Linux integrados con los que estoy trabajando, la emisión kill -TERM 1definitivamente provoca un reinicio (en realidad, revisando la ::shutdown:entrada y el script asociado en inittab).
SF.
Si init está en estado D por mucho tiempo, su sistema está realmente enfermo.
Joshua
6

Puedes reiniciar el initproceso. Esto es útil para realizar cambios inittabsin tener que reiniciar.

kill -HUP 1

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

jonescb
fuente
1
En implementaciones de initSé que esta señal no hace que el proceso se reinicie, sino solo para volver a cargar el /etc/inittabarchivo. --- systemctl daemon-reexecRealmente lo contrario systemd( initreemplazo en Linux) para volver a ejecutar
pabouk
4

sudo kill -INT 1(interrupción) reiniciará el sistema y sudo kill -SEGV 1(violación de segmentación) o sudo kill -ABRT 1(abortará) generará un kernel panic.

nota: se requiere sudo.

Commania
fuente
2

Bueno, la raíz puede matar el proceso de inicio en Linux:

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

Detalles:

kill -9 1 no 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

Entonces, corramos 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
fuente
Parece que el núcleo no ha sido la entrega SIGKILLal PID1puesto github.com/torvalds/linux/commit/... se fusionó.
Evgeny Vereshchagin
-2

Escriba sudo kill -INT 1, luego vea lo que sucede.

Siddhartha Biswas
fuente