By default, no, that's not allowed. Under Linux (fromman 2 kill):

The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally.

Pid 1 (init) can decide to allow itself to be killed, in which case the "kill" is basically a request for it to shut itself down. This is one possible way to implement thehalt command, though I'm not aware of anyinit that does that.

On a Mac, killinglaunchd (its init analogue) with signal 15 (SIGTERM) will immediately reboot the system, without bothering to shut down running programs cleanly. Killing it with the uncatchable signal 9 (SIGKILL) does nothing, showing that Mac'skill() semantics are the same as Linux's in this respect.

At the moment, I don't have a Linux box handy that I'm willing to experiment with, so the question of what Linux'sinit does with a SIGTERM will have to wait. And withinit replacement projects like Upstart and Systemd being popular these days, the answer could be variable.

UPDATE: On Linux,init explicitly ignores SIGTERM, so it does nothing. @jsbillings has information onwhat Upstart and Systemd do.

• 1
  Looks like you already found it, but for posterity:unix.stackexchange.com/questions/85364

  – Jander

  CommentedAug 2, 2013 at 19:38
• 5
  You can killinit with aSegmentation fault (SIGSEGV) signal, which will result in a kernel panic:kill -SEGV 1

  – KireinaHoro

  CommentedJan 16, 2016 at 9:09
• ^ Actually only BSD-style init allows this. systemd doesn’t and neither for the record does OpenRC or the old SysV init system from before systemd existed. In both of those cases, even signal 11 is ignored. Launchd on macOS, meanwhile,does do the same thing as BSD-style init — runningsudo killall -11 launchd on a Mac will likewise cause it to crash. I know this because I’ve done it on my MBP.

  – realkstrawn93

  CommentedJan 31, 2022 at 2:36
• Thedumb-init init system will shut itself down when you issue the commandkill 1. Though this applies primarily to containers which may not be what the OP was thinking of.

  – silverduck

  CommentedAug 26, 2022 at 5:34

The SysV init ignores SIGKILL or SIGTERM signals. The only signal that causes a change in state is SIGPWR as far as I can tell, which schedules a power-related shutdown.

It appears that Upstart and Systemd also do not respond to SIGKILL, and from my test, it appears that a SIGTERM causes upstart and systemd to re-exec.

I'm not sure what the other answerers are running but I'm pretty sure you can't kill -9 (SIGKILL) or kill -15 (SIGTERM) init (pid 1). Most likely, if you were able to, you'd get a kernel panic because init unexpectedly exited with a non-zero exit code, which would be less than ideal. It doesn't shut down your computer, or cause it to reboot.

• What if systemd(PID=1) run out of memory? Will it active a OOM killer who will attempt to kill systemd?

  – TJM

  CommentedMay 19, 2021 at 1:29
• This answer is over 10 years old, but I believe that the kernel code specifically ignores any PID == 1 and several other kernel thread processes.

  – jsbillings

  CommentedMay 19, 2021 at 2:19

Technically yes, root can issue a SIGKILL to init. init, however, differs from most, nearly all in fact, other processes in that it is permitted to trap and ignore the signal.

You can, loosely, kill init by issuing akill -TERM 1 which would be analogous to issuing ahalt orshutdown in that init will pass the signal to all children, essentially all other processes, before honoring the signal itself.

Please note: performing this commandwill shutdown your system.

For flavor; one type of other process that can "ignore" a SIGKILL is one in uninterruptible sleep, such as one waiting for i/o. Such a process could be found by issuing aps axo stat,comm where processes with a status 'D' are uninterruptible.

• 6
  Actually, from my tests,kill -TERM 1 will do nothing but cause init to re-exec itself on most linux systems, and that the only thing you could do to cause a system to shutdown your system is to runkill -PWR 1

  – jsbillings

  CommentedFeb 15, 2011 at 19:08
• @jsbillings On the embedded Linux SBCs I'm working with issuingkill -TERM 1 definitely causes a reboot (actually going through the::shutdown: entry and associated script in inittab.)

  – SF.

  CommentedMar 9, 2016 at 11:32
• If init is in a D state for long your system is really sick.

  – Joshua

  CommentedJul 28, 2016 at 15:14

You can restart theinit process. This is useful for making changes toinittab without having to reboot.

kill -HUP 1

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

• 3
  In implementations ofinit I know this signal does not make the process to restart but just to re-load the/etc/inittab file. --- Contrarysystemctl daemon-reexec really makessystemd (init replacement on Linux) to re-execute.

  – pabouk - Ukraine stay strong

  CommentedApr 30, 2015 at 13:45

sudo kill -INT 1 (interrupt) will restart system, andsudo kill -SEGV 1, ( segmentation violation) orsudo kill -ABRT 1(abort) will generate a kernel panic.

note:sudo is required.

Well, root can kill init process on Linux:

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

Details:

kill -9 1 doesn't work:

-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

So, let's runstrace:

-bash-4.3# echo 1 >/proc/sys/kernel/ftrace_dump_on_oops-bash-4.3# strace -p 1 -o OUT &[1] 179strace: Process 1 attached-bash-4.3# echo "My second attempt" >/sys/kernel/debug/tracing/trace_marker-bash-4.3# kill -9 1bash-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]

• 1
  It seems that the kernel hasn't been deliveringSIGKILL toPID1 sincegithub.com/torvalds/linux/commit/… was merged.

  – Evgeny

  CommentedMar 30, 2018 at 0:13

If you send SIGILL or SIGSEGV to launchd on a Mac, it forces a kernel panic (tested on an M1 MacBook Pro).

Sending such signals to systemd or to init on Linux, however, does nothing —kill -11 1 exits without doing anything,killall -11 systemd hangs, andkill -4 1 andkillall -4 systemd also hang.

• root
• init