Il root kill può essere processato?

38

Può root kill init process (il processo con pid 1)? Quali sarebbero le sue conseguenze?

root  init 
— Dharmit
fonte

Risposte:

38

Per impostazione predefinita, no, non è consentito. Sotto Linux (da man 2 kill):

Gli unici segnali che possono essere inviati all'ID processo 1, il processo init, sono quelli per i quali init ha esplicitamente installato gestori di segnali. Questo viene fatto per garantire che il sistema non venga accidentalmente disattivato.

Pid 1 (init) può decidere di lasciarsi uccidere, nel qual caso la "uccisione" è fondamentalmente una richiesta per chiudersi. Questo è un modo possibile per implementare il haltcomando, anche se non sono a conoscenza di nessuno initche lo faccia.

Su un Mac, uccidere launchd(il suo analogo init) con il segnale 15 (SIGTERM) riavvierà immediatamente il sistema, senza preoccuparsi di arrestare i programmi in esecuzione in modo pulito. Ucciderlo con il segnale inattaccabile 9 (SIGKILL) non fa nulla, dimostrando che la kill()semantica di Mac è la stessa di Linux in questo senso.

Al momento, non ho una Linux box a portata di mano con cui sono disposto a sperimentare, quindi la domanda su cosa fa Linux initcon un SIGTERM dovrà attendere. E con i initprogetti di sostituzione come Upstart e Systemd che sono popolari in questi giorni, la risposta potrebbe essere variabile.

AGGIORNAMENTO : Su Linux, initignora esplicitamente SIGTERM, quindi non fa nulla. @jsbillings ha informazioni su cosa fanno Upstart e Systemd.

— Jander
fonte
1
Sembra che tu l'abbia già trovato, ma per i posteri: unix.stackexchange.com/questions/85364
— Jander
1
Puoi uccidere initcon un segnale Segmentation fault( SIGSEGV), che si tradurrà in un panico nel kernel:kill -SEGV 1
— Johnson Steward,
13

SysV init ignora i segnali SIGKILL o SIGTERM. L'unico segnale che provoca un cambiamento di stato è SIGPWR, per quanto ne so, che pianifica un arresto relativo all'alimentazione.

Sembra che anche Upstart e Systemd non rispondano a SIGKILL e dal mio test, sembra che un SIGTERM causi il riavvio di upstart e systemd.

Non sono sicuro di cosa stiano lavorando gli altri risponditori, ma sono abbastanza sicuro che non puoi uccidere -9 (SIGKILL) o uccidere -15 (SIGTERM) init (pid 1). Molto probabilmente, se tu fossi in grado, otterrai un panico nel kernel perché init è uscito inaspettatamente con un codice di uscita diverso da zero, che sarebbe meno che ideale. Non spegne il computer o non si riavvia.

— jsbillings
fonte
6

Tecnicamente sì, root può emettere un SIGKILL per init. init, tuttavia, differisce dalla maggior parte, quasi tutti in realtà, da altri processi in quanto è consentito intercettare e ignorare il segnale.

Puoi, liberamente, uccidere init emettendo un kill -TERM 1che sarebbe analogo all'emissione di un halto shutdownin quell'init passerà il segnale a tutti i bambini, essenzialmente a tutti gli altri processi, prima di onorare il segnale stesso.

Si prega di notare: l'esecuzione di questo comando volontà spegnere il sistema.

Per sapore; un tipo di altro processo che può "ignorare" un SIGKILL è uno in modalità di sospensione ininterrotta, come uno in attesa di I / O. Tale processo potrebbe essere trovato emettendo un ps axo stat,commprocesso in cui i processi con uno stato 'D' sono ininterrotti.

— Tok
fonte
2
In realtà, dai miei test, kill -TERM 1non farò altro che causare la re-esecuzione di init sulla maggior parte dei sistemi Linux, e che l'unica cosa che potresti fare per causare l'arresto di un sistema è l'esecuzionekill -PWR 1
— jsbillings,
@jsbillings Sugli SBC Linux incorporati, sto lavorando con l'emissione kill -TERM 1provoca sicuramente un riavvio (passando effettivamente attraverso la ::shutdown:voce e lo script associato in inittab.)
— SF.
Se init è a lungo in uno stato D, il sistema è davvero malato.
— Giosuè,
4

sudo kill -INT 1(interrompi) riavvierà il sistema e sudo kill -SEGV 1(violazione della segmentazione) o sudo kill -ABRT 1(interrompi) genererà un panico nel kernel.

nota: sudo è richiesto.

— ComMania
fonte
2

Bene, root può uccidere il processo di init su Linux:

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

Dettagli:

kill -9 1 non funziona:

-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

Quindi, eseguiamo 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
Sembra che il kernel non stia offrendo SIGKILLda PID1quando github.com/torvalds/linux/commit/… è stato unito.
— Evgeny Vereshchagin,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.