Le processus root kill init peut-il?

38

Le processus root kill init peut-il (processus avec pid 1)? Quelles seraient ses conséquences?

root init Dharmit
la source

Réponses:

38

Par défaut, non, ce n'est pas autorisé. Sous Linux (depuis man 2 kill):

Les seuls signaux pouvant être envoyés au processus ID 1, le processus init, sont ceux pour lesquels init a explicitement installé des gestionnaires de signaux. Ceci est fait pour s'assurer que le système n'est pas arrêté accidentellement.

Pid 1 (init) peut décider de se laisser tuer, auquel cas le "kill" est essentiellement une demande pour qu'il se ferme lui-même. C'est un moyen possible d'implémenter la haltcommande, bien que je ne sache pas initqu'il en soit ainsi.

Sur un Mac, la suppression launchd(son signal analogique) avec le signal 15 (SIGTERM) redémarre immédiatement le système, sans avoir à arrêter d'éteindre les programmes en cours d'exécution. Le tuer avec le signal non joignable 9 (SIGKILL) ne fait rien, montrant que la kill()sémantique de Mac est la même que celle de Linux à cet égard.

Pour le moment, je ne suis pas prêt à expérimenter initavec une machine Linux, alors la question de savoir ce que fait Linux avec un SIGTERM devra attendre. Et avec initles projets de remplacement comme Upstart et Systemd étant populaires ces jours-ci, la réponse pourrait être variable.

UPDATE : Sous Linux, initignore explicitement SIGTERM, donc il ne fait rien. @jsbillings a des informations sur ce que font Upstart et Systemd.

Jander
la source
1
On dirait que vous l'avez déjà trouvé, mais pour la postérité: unix.stackexchange.com/questions/85364
Jander
1
Vous pouvez tuer initavec un signal Segmentation fault( SIGSEGV), ce qui entraînera une panique du noyau:kill -SEGV 1
Johnson Steward
13

Le SysV init ignore les signaux SIGKILL ou SIGTERM. Le seul signal qui provoque un changement d'état est SIGPWR, autant que je sache, qui programme un arrêt lié à l'alimentation.

Il semble que Upstart et Systemd ne répondent pas non plus à SIGKILL et, d'après mon test, il semble qu'un SIGTERM provoque la ré-exécution de upstart et de systemd.

Je ne suis pas sûr de savoir ce que les autres répondeurs utilisent, mais je suis à peu près sûr que vous ne pouvez ni tuer -9 (SIGKILL) ni tuer -15 (SIGTERM) init (pid 1). Très probablement, si vous le pouviez, vous auriez une panique dans le noyau car init est sorti de manière inattendue avec un code de sortie non nul, ce qui serait loin d'être idéal. Cela n'arrête pas votre ordinateur et ne le redémarre pas.

jsbillings
la source
6

Techniquement oui, root peut émettre un SIGKILL à init. Cependant, init diffère de la plupart des autres processus, voire presque tous, en ce sens qu'il est autorisé à intercepter et à ignorer le signal.

Vous pouvez, en gros, tuer init en en émettant une action kill -TERM 1qui serait analogue à émettre en haltou shutdowndans cet init transmettra le signal à tous les enfants, essentiellement à tous les autres processus, avant de respecter le signal lui-même.

S'il vous plaît noter: l' exécution de cette commande volonté d' éteindre votre système.

Pour la saveur; Un type de processus pouvant "ignorer" un SIGKILL est un processus en sommeil ininterruptible, tel qu'un processus en attente d'E / S. Un tel processus pourrait être trouvé en émettant un ps axo stat,commoù les processus avec un statut 'D' sont ininterruptibles.

Tok
la source
2
En fait, d'après mes tests, kill -TERM 1rien ne fera qu'init se re-exécuter sur la plupart des systèmes Linux, et que la seule chose que vous puissiez faire pour qu'un système kill -PWR 1
arrête
@jsbillings Sur les SBC Linux intégrés avec lesquels je travaille, le kill -TERM 1redémarrage provoque définitivement un redémarrage (en passant par l' ::shutdown:entrée et le script associé dans inittab.)
SF.
Si init est dans un état D pendant longtemps, votre système est vraiment malade.
Joshua
6

Vous pouvez redémarrer le initprocessus. Ceci est utile pour apporter des modifications inittabsans avoir à redémarrer.

kill -HUP 1

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

jonescb
la source
1
Dans les implémentations de initje sais que ce signal ne fait pas que le processus redémarre mais se contente de recharger le /etc/inittabfichier. --- Contrary systemctl daemon-reexecfait vraiment systemd( initremplacement sur Linux) à ré-exécuter.
Pabouk
4

sudo kill -INT 1(interruption) redémarre le système et sudo kill -SEGV 1, (violation de segmentation) ou sudo kill -ABRT 1(annulation) génère une panique du noyau.

note: sudo est requis.

ComMania
la source
2

Eh bien, root peut tuer le processus init sous Linux:

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

Détails:

kill -9 1 ne fonctionne pas:

-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

Alors courons 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
la source
Il semble que le noyau n’ait pas été livré SIGKILLà PID1depuis la fusion de github.com/torvalds/linux/commit/… .
Evgeny Vereshchagin
-2

Tapez sudo kill -INT 1, puis voyez ce qui se passe.

Siddhartha Biswas
la source