Kann Root Kill Init verarbeiten?

38

Kann root den Init-Prozess töten (der Prozess mit PID 1)? Was wären ihre Konsequenzen?

root  init 
— Dharmit
quelle

Antworten:

38

Standardmäßig ist dies nicht zulässig. Unter Linux (von man 2 kill):

Die einzigen Signale, die an die Prozess-ID 1, den Init-Prozess, gesendet werden können, sind solche, für die init explizit Signalhandler installiert hat. Auf diese Weise wird sichergestellt, dass das System nicht versehentlich heruntergefahren wird.

Pid 1 (init) kann entscheiden, sich selbst töten zu lassen. In diesem Fall ist "kill" im Grunde eine Aufforderung, sich selbst herunterzufahren. Dies ist eine Möglichkeit, den haltBefehl zu implementieren , obwohl mir keiner bewusst ist, der initdas tut.

Auf einem Mac launchdstartet das Beenden (seines Init-Analogons) mit Signal 15 (SIGTERM) das System sofort neu, ohne die laufenden Programme sauber herunterzufahren. Wenn Sie es mit dem unauffangbaren Signal 9 (SIGKILL) töten, hat dies nichts zu bedeuten. Dies zeigt, dass die kill()Semantik von Mac in dieser Hinsicht mit der von Linux identisch ist.

Im Moment habe ich keine Linux-Box zur Hand, mit der ich experimentieren möchte, daher muss die Frage, was Linux initmit einem SIGTERM macht, warten. Und mit initErsatzprojekten wie Upstart und Systemd, die heutzutage populär sind, könnte die Antwort variabel sein.

UPDATE : Unter Linux wird initSIGTERM explizit ignoriert, sodass nichts unternommen wird. @jsbillings hat Informationen darüber, was Upstart und Systemd tun.

— Jander
quelle
1
Sieht so aus, als hätten Sie es bereits gefunden, aber für die Nachwelt: unix.stackexchange.com/questions/85364
— Jander
1
Sie können initmit einem Segmentation fault( SIGSEGV) Signal töten , was zu einer Kernel-Panik führt:kill -SEGV 1
— Johnson Steward
13

Der SysV-Init ignoriert SIGKILL- oder SIGTERM-Signale. Das einzige Signal, das eine Zustandsänderung hervorruft, ist, soweit ich das beurteilen kann, SIGPWR, das eine leistungsbezogene Abschaltung vorsieht.

Es scheint, dass Upstart und Systemd auch nicht auf SIGKILL reagieren, und aus meinem Test geht hervor, dass ein SIGTERM dazu führt, dass Upstart und Systemd erneut ausgeführt werden.

Ich bin mir nicht sicher, wie die anderen Antworten lauten, aber ich bin mir ziemlich sicher, dass Sie -9 (SIGKILL) oder -15 (SIGTERM) init (pid 1) nicht töten können. Wenn Sie in der Lage wären, würden Sie höchstwahrscheinlich eine Kernel-Panik bekommen, weil init unerwartet mit einem Exit-Code ungleich Null beendet wurde, was weniger als ideal wäre. Der Computer wird nicht heruntergefahren oder neu gestartet.

— jsbillings
quelle
6

Technisch gesehen kann root ein SIGKILL an init ausgeben. init unterscheidet sich jedoch von den meisten, fast allen anderen Prozessen darin, dass es erlaubt ist, das Signal einzufangen und zu ignorieren.

Sie können init locker töten, indem Sie a ausgeben, kill -TERM 1was analog zur Ausgabe von a wäre, haltoder shutdownin diesem init wird das Signal an alle untergeordneten Elemente, im Wesentlichen alle anderen Prozesse, übergeben, bevor das Signal selbst berücksichtigt wird.

Bitte beachten Sie: Wenn Sie diesen Befehl ausführen, wird Ihr System heruntergefahren.

Für den Geschmack; Eine andere Art von Prozess, der ein SIGKILL "ignorieren" kann, ist der ununterbrochene Schlaf, z. B. der Wartezustand auf E / A. Ein solcher Prozess könnte gefunden werden, indem ein ausgegeben wird, ps axo stat,commbei dem Prozesse mit dem Status 'D' nicht unterbrechbar sind.

— Tok
quelle
2
Eigentlich aus meinen Tests, kill -TERM 1tun nichts anderes als Ursache init Wieder exec sich auf den meisten Linux - Systemen, und dass das einzige , was Sie tun können , ein System zum Herunterfahren Ihres Systems zu verursachen , ist zu laufenkill -PWR 1
— jsbillings
@jsbillings Auf den eingebetteten Linux-SBCs, mit denen ich arbeite, führt das Ausstellen kill -TERM 1definitiv zu einem Neustart (tatsächlich wird der ::shutdown:Eintrag und das zugehörige Skript in inittab durchlaufen .)
— SF.
Wenn sich init für lange Zeit in einem D-Zustand befindet, ist Ihr System wirklich krank.
— Joshua
6

Sie können den initProzess neu starten . Dies ist nützlich, um Änderungen vorzunehmen, inittabohne einen Neustart durchführen zu müssen.

kill -HUP 1

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

— jonescb
quelle
1
In Implementierungen von initIch weiß, dieses Signal macht den Prozess nicht neu zu starten, sondern nur die /etc/inittabDatei neu zu laden . --- Gegenteil systemctl daemon-reexecwirklich macht systemd( initErsatz unter Linux), um erneut auszuführen.
— Pabouk
4

sudo kill -INT 1(Interrupt) startet das System neu und sudo kill -SEGV 1(Segmentierungsverletzung) oder sudo kill -ABRT 1(Abbruch) erzeugt eine Kernel-Panik.

hinweis: sudo ist erforderlich.

— ComMania
quelle
2

Nun, root kann den init-Prozess unter Linux beenden:

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

Einzelheiten:

kill -9 1 funktioniert nicht:

-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

Also, lass uns laufen 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
quelle
Es scheint, dass der Kernel nicht mehr ausgeliefert wurde SIGKILL, PID1seit github.com/torvalds/linux/commit/… zusammengeführt wurde.
— Evgeny Vereshchagin
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.