Чи може корінь вбити процес init?

Чи може root вбити процес init (процес із Pid 1)? Якими були б його наслідки?

За замовчуванням ні, це заборонено. Під Linux (від man 2 kill):

Єдиними сигналами, які можуть бути надіслані до ідентифікатора обробки 1, процесу init, є ті, для яких init явно встановив обробники сигналів. Це робиться для того, щоб система не була зруйнована випадково.

Pid 1 (ініт) може вирішити, щоб дозволити собі бути вбитим, і в цьому випадку "вбивство" - це в основному прохання про його закриття. Це один із можливих способів реалізації haltкоманди, хоча я не знаю жодного, initхто це робить.

На Mac, вбивство launchd(його ініталогічний аналог) із сигналом 15 (SIGTERM) негайно перезавантажить систему, не намагаючись чисто закрити запущені програми. Убивання його за допомогою нерозбірливого сигналу 9 (SIGKILL) нічого не робить, показуючи, що kill()семантика Mac в цьому відношенні така ж, як і Linux.

На даний момент у мене немає зручної скриньки для Linux, з якою я хочу експериментувати, тому питання, що initробить Linux із системою SIGTERM, доведеться почекати. І з initпопулярними в наші дні проекти заміщення, такі як Upstart і Systemd, відповідь може бути змінною.

ОНОВЛЕННЯ : У Linux initявно ігнорує SIGTERM, тому він нічого не робить. @jsbillings містить інформацію про те, що роблять Upstart і Systemd.

Ініт SysV ігнорує сигнали SIGKILL або SIGTERM. Наскільки я можу сказати, єдиний сигнал, який викликає зміну стану, - це SIGPWR, який планує відключення, пов'язане з живленням.

Схоже, Upstart і Systemd також не реагують на SIGKILL, і з мого тестування видно, що SIGTERM викликає перезапуск і systemd для повторного виконання.

Я не впевнений, що працюють інші відповіді, але я впевнений, що ви не можете вбити -9 (SIGKILL) або -15 (SIGTERM) init (pid 1). Швидше за все, якщо б вам вдалося, ви отримаєте паніку з ядром, тому що init несподівано вийшов з ненульовим кодом виходу, що було б менше, ніж ідеально. Це не вимикає комп'ютер і не викликає його перезавантаження.

Технічно так, root може видавати SIGKILL для init. Однак init, однак, відрізняється від більшості, майже всіх насправді інших процесів тим, що дозволено захоплювати та ігнорувати сигнал.

Ви можете вільно вбити init, видавши сигнал, kill -TERM 1який був би аналогічним видачі a haltабо shutdownв тому, що ініт передасть сигнал всім дітям, по суті всім іншим процесам, перш ніж вшанувати сам сигнал.

Зверніть увагу: виконання цієї команди призведе до вимкнення вашої системи.

Для аромату; один тип іншого процесу, який може "ігнорувати" SIGKILL, - це той, що перебуває в режимі безперебійного сну, наприклад такий, який чекає вводу / виводу. Такий процес можна було б знайти, видавши, ps axo stat,commде процеси зі статусом "D" є безперебійними.

Ви можете перезапустити initпроцес. Це корисно для внесення змін inittabбез необхідності перезавантаження.

kill -HUP 1

Джерело: http://www.cyberciti.biz/faq/linux-unix-kill-hup-1-reread-etcinittab-file/

sudo kill -INT 1(переривання) перезапустить систему, і sudo kill -SEGV 1(порушення сегментації) або sudo kill -ABRT 1(перервати) породжує паніку ядра.

Примітка: Судо потрібно.

Ну, root може вбити процес init в Linux:

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

Деталі:

kill -9 1 не працює:

-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

Отже, запустимо 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]

Наберіть sudo kill -INT 1, а потім подивіться, що станеться.