Может ли root уничтожить процесс инициализации?

38

Может ли root уничтожить процесс init (процесс с pid 1)? Каковы будут его последствия?

root init Dharmit
источник

Ответы:

38

По умолчанию нет, это не разрешено. Под Linux (с man 2 kill):

Единственные сигналы, которые могут быть отправлены процессу ID 1, процессу init, - это сигналы, для которых init явно установил обработчики сигналов. Это сделано для того, чтобы система не была случайно отключена.

Pid 1 (init) может решить позволить себе быть убитым, и в этом случае «kill» - это, по сути, запрос на его отключение. Это один из возможных способов реализации haltкоманды, хотя я не знаю ни одного init, кто это делает.

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

На данный момент у меня нет под рукой Linux-бокса, с которым я бы хотел поэкспериментировать, поэтому вопрос о том, что Linux initделает с SIGTERM, придется подождать. А в связи с тем, что initпроекты замены, такие как Upstart и Systemd, сейчас популярны, ответ может быть переменным.

ОБНОВЛЕНИЕ : В Linux initявно игнорирует SIGTERM, поэтому он ничего не делает. @jsbillings обладает информацией о том, что делают Upstart и Systemd.

Jander
источник
1
Похоже , вы уже нашли, но для потомства: unix.stackexchange.com/questions/85364
Jander
1
Вы можете убить initс помощью Segmentation fault( SIGSEGV) сигнала, который приведет к панике ядра:kill -SEGV 1
Джонсон Стюард
13

SysV init игнорирует сигналы SIGKILL или SIGTERM. Насколько я могу судить, единственным сигналом, вызывающим изменение состояния, является SIGPWR, который планирует отключение, связанное с питанием.

Похоже, что Upstart и Systemd также не отвечают на SIGKILL, и из моего теста выяснилось, что SIGTERM вызывает повторный запуск upstart и systemd.

Я не уверен, что работают другие ответчики, но я уверен, что вы не можете убить -9 (SIGKILL) или убить -15 (SIGTERM) init (pid 1). Скорее всего, если бы вы смогли, вы бы испытали панику ядра, потому что init неожиданно завершился с ненулевым кодом завершения, что было бы не идеально. Он не выключает компьютер и не приводит к перезагрузке.

jsbillings
источник
6

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

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

Пожалуйста , обратите внимание: При выполнении этой команды Волю перегрузить систему.

Для аромата; один тип другого процесса, который может «игнорировать» SIGKILL, - это процесс в непрерывном сне, например, ожидание ввода-вывода. Такой процесс может быть найден путем выдачи там, ps axo stat,commгде процессы со статусом «D» являются бесперебойными.

Tok
источник
2
На самом деле, из моих тестов, kill -TERM 1ничего не произойдет, кроме как заставить init повторно выполнить себя на большинстве систем linux, и что единственное, что вы можете сделать, чтобы заставить систему выключить вашу систему, это запуститьkill -PWR 1
jsbillings
@jsbillings На встроенных SBC Linux, с которыми я работаю, kill -TERM 1определенно происходит перезагрузка (на самом деле происходит ::shutdown:запись и связанный скрипт в inittab.)
SF.
Если init долго находится в состоянии D, ваша система действительно больна.
Джошуа
6

Вы можете перезапустить initпроцесс. Это полезно для внесения изменений inittabбез перезагрузки.

kill -HUP 1

Источник: http://www.cyberciti.biz/faq/linux-unix-kill-hup-1-reread-etcinittab-file/

jonescb
источник
1
В реализациях, которые initя знаю, этот сигнал не заставляет процесс перезапускаться, а просто перезагружает /etc/inittabфайл. --- Наоборот systemctl daemon-reexecдействительно делает systemd( initзамена в Linux) для повторного выполнения.
Пабук
4

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

примечание: требуется sudo.

ComMania
источник
2

Ну, root может убить процесс инициализации в 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]
Евгений Верещагин
источник
Кажется, что ядро ​​не доставлялось SIGKILLс PID1момента объединения github.com/torvalds/linux/commit/… .
Евгений Верещагин
-2

Типа sudo kill -INT 1, тогда посмотри что получится.

Сиддхартха Бисвас
источник