1

I know that PID 1 is init. Now I would like to knom, can I replace init process ID to another one and assign to PID 1 a new process. If yes how can I do that?

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Agyol
  • 133
  • Sure, on linux https://unix.stackexchange.com/questions/34462/why-does-linux-allow-init-bin-bash – thrig Jun 07 '17 at 20:08
  • Note: PID 1 has also a semantic meaning in POSIX. So process with PID 1 must be capable of doing some operation and not doing others. E.g. Kernel will put the zombies to PID 1, and it should care about zombies before they block your system (too many processes). Signals to "1" are also handled differently – Giacomo Catenazzi Jun 07 '17 at 21:06
  • Thanks all for your response. I think I found the response to the question partly. PID 1 is not reserved ID actually. So, for this reason, you can replace this. The problem is as you mentioned it needs modifying the kernel not only for booting, also process which is dependent from the init. But now I don't know how can I do that :-). Thanks for patiently responding to my question. – Agyol Jun 07 '17 at 21:52
  • @GiacomoCatenazzi Could you please write your response separately.Because this a response of my question. I would like to mark this as response – Agyol Jun 07 '17 at 22:31

2 Answers2

9

The first process that is started at boot time receives PID 1.

The first process that is started at boot time has a job: it has to start all other processes, directly or indirectly. All processes¹ are ultimately descendants of this, since apart from the kernel running a program at boot time the only way a process gets created is that some process executed a system call to create a new process.

The process whose PID is 1 has a job: if a process dies while it has running child processes, the children's parent process ID is set to 1. When the children die, PID 1 should reap them, i.e. call the wait system call, otherwise a zombie of the child process stays behind.

The various programs called init (there are multiple implementations) perform both of these jobs.

The Linux kernel has a command line argument to change which executable is executed as the first process². It can be used to run any executable, but if that executable doesn't perform the jobs of init, the system isn't going to run normally. This feature is mostly used to enter a system repair mode, e.g. only running a shell on the console and nothing else.

Once the system has started normally, it is not possible to replace PID 1 because init doesn't die. Not only does init not die, because it's programmed to run forever (init is supposed to keep running until the system shuts down), but it even gets a special protection from signals that would kill other processes, such as SIGKILL.

Linux has a PID namespace feature that allows defining a subsystem with its own set of process IDs. The processes in a PID namespace have different PIDs when viewed from inside the namespace and from outside the namespace. The first process in the namespace gets PID 1 in the namespace. Outside the namespace it won't have PID 1 (unless init chose to enter a new PID namespace, but init doesn't do that because that would prevent it from doing its job).

¹ This isn't completely true, some kernels have other ways to launch a process. For example Linux launches modprobe when some hardware is discovered under certain circumstances. But descendants of init account for a vast majority of processes.
² First after the initramfs or initrd.

0

In some ways init is special as noted by Gilles. If init dies, in most cases you get a kernel panic, which is why any reputable author of init will do much to avoid that happening. On the other hand it is much like any other program in that aside from dealing with zombie processes, you can actually use any program as init. cat works just fine but is not exactly useful. one of the ways that init is completely ordinary is that it can call execlve (exec and friends) which replaces one program with another using the same pid. this is used for example by initial root disks to run the real init after mounting the drive it will be run from.

hildred
  • 5,829
  • 3
  • 31
  • 43
  • Not really. kernel will restart init. It just "panic" is the restart are very frequently, like having a broken libc. – Giacomo Catenazzi Jun 08 '17 at 07:10
  • 1
    @GiacomoCatenazzi, hate to burst your bubble, but if you pass the wrong root device to a Debian initrd, the mount will fail, which causes the exec to fail which leads to an exit which panics the kernel on the first try, every time. – hildred Jun 08 '17 at 15:34
  • Right, but it is not init that crash. initrd is handled by kernel. kernel mount the root device, and so kernel know he cannot do alternative. A crash in init could possibly restored by restarting init, so it is tried again. Both are handled in the same file in kernel sources. – Giacomo Catenazzi Jun 08 '17 at 18:08