Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can root kill init process (the process with pid 1)? What would be its consequences?

share|improve this question
up vote 26 down vote accepted

By default, no, that's not allowed. Under Linux (from man 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 the halt command, though I'm not aware of any init that does that.

On a Mac, killing launchd (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's kill() 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's init does with a SIGTERM will have to wait. And with init 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 on what Upstart and Systemd do.

share|improve this answer
How do you get a list of the signals that init is specifically setup to handle? – slm Aug 2 '13 at 19:01
Looks like you already found it, but for posterity: unix.stackexchange.com/questions/85364 – Jander Aug 2 '13 at 19:38
You can kill init with a Segmentation fault (SIGSEGV) signal, which will result in a kernel panic: kill -SEGV 1 – Johnson Steward Jan 16 at 9:09

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.

share|improve this answer

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 a kill -TERM 1 which would be analogous to issuing a halt or shutdown in that init will pass the signal to all children, essentially all other processes, before honoring the signal itself.

Please note: performing this command will 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 a ps axo stat,comm where processes with a status 'D' are uninterruptible.

share|improve this answer
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 run kill -PWR 1 – jsbillings Feb 15 '11 at 19:08
@jsbillings On the embedded Linux SBCs I'm working with issuing kill -TERM 1 definitely causes a reboot (actually going through the ::shutdown: entry and associated script in inittab.) – SF. Mar 9 at 11:32
If init is in a D state for long your system is really sick. – Joshua 12 hours ago

You can restart the init process. This is useful for making changes to inittab without having to reboot.

kill -HUP 1

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

share|improve this answer
In implementations of init I know this signal does not make the process to restart but just to re-load the /etc/inittab file. --- Contrary systemctl daemon-reexec really makes systemd (init replacement on Linux) to re-execute. – pabouk Apr 30 '15 at 13:45

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

note: sudo is required.

share|improve this answer

Type sudo kill -INT 1, then see what happens.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.