Вопросы Теги

Может корневое уничтожение init процесс?

Оставление свободного места для важных корневых процессов (и возможные спасательные действия) является одной причиной.

Но существует другой. Ext3 довольно хорош в предотвращении фрагментации файловой системы, но после того как Вы добираетесь выше полных приблизительно 95%, то поведение падает с утеса, и внезапно производительность файловой системы становится путаницей. Так отъезд зарезервированных 5% дает Вам буфер против этого.

Ext4 должен быть лучше в этом, как объяснил разработчик/гуру файловой системы Linux Theodore Ts'o:

Если Вы обнулите зарезервированное количество блока, то оно не будет влиять на производительность очень кроме того, если Вы будете работать в течение долгих промежутков времени (с большим количеством файла, создает и удаляет), в то время как файловая система почти полна (т.е. скажите выше 95%), в которой точке Вы подвергнетесь проблемам фрагментации. Средство выделения мультиблока Ext4 является намного большим количеством стойкой фрагментации, потому что это пытается намного тяжелее найти непрерывные блоки, поэтому даже если Вы не активируете другие ext4 опции, то Вы будете видеть лучшие результаты, просто монтирующие ext3 файловую систему с помощью ext4, прежде чем файловая система станет абсолютно полной.

Если Вы будете просто использовать файловую систему для долгосрочного архива, где файлы не изменяются очень часто (т.е. огромный mp3 или видеомагазин), это, очевидно, не будет иметь значения.

39
15.02.2011, 17:48
7 ответов

По умолчанию, нет, это не позволяется. В соответствии с Linux (от man 2 kill):

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

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

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

В данный момент у меня нет поля Linux удобным, что я готов экспериментировать с, таким образом, вопрос какой Linux init делает с SIGTERM, должен будет ожидать. И с init заменяющие проекты как Upstart и Systemd, являющийся популярным в эти дни, ответ мог быть переменным.

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

38
27.01.2020, 19:35

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

Кажется, что Upstart и Systemd также не отвечают на SIGKILL, и от моего теста, кажется, что SIGTERM вызывает выскочку и systemd передолжностному лицу.

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

13
27.01.2020, 19:35

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

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

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

Для разновидности; один тип другого процесса, который может "проигнорировать" SIGKILL, один в бесперебойном сне, таком как одно ожидание i/o. Такой процесс мог быть найден путем издания a ps axo stat,comm где процессы с состоянием 'D' бесперебойны.

6
27.01.2020, 19:35
  • 1
    На самом деле, от моих тестов, kill -TERM 1 сделает только причину init передолжностному лицу саму в большинстве систем Linux, и что единственная вещь, которую Вы могли сделать, чтобы заставить систему завершать работу Вашей системы, состоит в том, чтобы работать kill -PWR 1 –  jsbillings 15.02.2011, 21:08
  • 2
    @jsbillings На встроенном Linux SBCs я работаю с изданием kill -TERM 1 определенно вызывает перезагрузку (на самом деле прохождение через ::shutdown: запись и связанный сценарий в inittab.) –  SF. 09.03.2016, 13:32
  • 3
    Если init находится в D долгое время, указывают, что Ваша система действительно больна. –  Joshua 28.07.2016, 18:14

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

kill -HUP 1

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

6
27.01.2020, 19:35
  • 1
    В реализациях init Я знаю, что этот сигнал не делает процесс, чтобы перезапустить, но только перезагрузить /etc/inittab файл. Обратное--- systemctl daemon-reexec действительно делает systemd (init замена на Linux), чтобы повторно выполниться. спасибо –  pabouk 30.04.2015, 16:45

Ввести sudo kill -INT 1, затем посмотрите то, что происходит.

-2
27.01.2020, 19:35
[1277] sudo kill -INT 1[112756] (прерывание) перезапустит систему, и [112757]sudo kill -SEGV 1[112758], ( нарушение сегментации) или [112759]sudo kill -ABRT 1[112760](abort) сгенерирует панику ядра.[1278]note: требуется sudo.[112279].
4
27.01.2020, 19:35

Что ж, 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]
3
20.08.2021, 13:37

Теги

Похожие вопросы