First, “ancestor” isn't the same thing as “parent”. The ancestor can be the parent's parent's … parent's parent, and the kernel only keeps track of one level.
However, when a process dies, its children are adopted by init, so you will see a lot of processes whose parent is 1 on a typical system.
Modern Linux systems additionally have a few processes that execute kernel code, but are managed as user processes, as far as scheduling is concerned. (They don't obey the usual memory management rules since they're running kernel code.) These processes are all spawned by kthreadd (it's the init of kernel threads). You can recognize them by their parent process ID (2) or, usually, by the fact that ps lists them with a name between square brackets or by the fact that /proc/2/exe (normally a symbolic link to the process executable) can't be read.
Processes 1 (init) and 2 (kthreadd) are created directly by the kernel at boot time, so they don't have a parent. The value 0 is used in their ppid field to indicate that. Think of 0 as meaning “the kernel itself” here.
Linux also has some facilities for the kernel to start user processes whose location is indicated via a sysctl parameter in certain circumstances. For example, the kernel can trigger module loading events (e.g. when new hardware is discovered, or when some network protocols are first used) by calling the program in the kernel.modprobe sysctl value. When a program dumps core, the kernel calls the program indicated by kernel.core_pattern if any.
For the second question, the answer is no and you should have a look at Resources for portable shell programming.
As for the first part - first of all, you certainly have to be careful. I'd say perform several tests to make sure - because the fact that someone does have systemd (for ex.) installed, does not mean it is actually used as the default init. Also, looking at /proc/1/comm can be misleading, because some installations of various init programs can automatically make /sbin/init a symlink hardlink or even a renamed version of their main program.
Maybe the most useful thing could be to look at the init scripts type - because those are what you'll actually be creating, no matter what runs them.
As a side note, you might also have a look at OpenRC which aims to provide a structure of init scripts that is compatible with both Linux and BSD systems.
Best Answer
Don't conflate processes and programs. There's one process #1, but it can be running one of a number of different programs.
systemdprogram from the systemd package:SIGWINCHandSIGPWRtoSIGRTMIN + 4.system-managerprogram from the nosh package:systemd, with the same meanings where applicable.initprogram from upstart:initctlFIFO.finit:initctlFIFO.initthen:initctlFIFO.Some notes:
SIGWINCH,SIGINT, andSIGPWR, and various widespread system utility programs.systemdand the noshsystem-managerextend this with signals that command system state changes (such as shutting down and powering off the system).SIGPWR, for example.finitrecognizes a different set of non-system-mandated extended signals, includingSIGSTOPandSIGCONT.initctlFIFO API in the program that runs as process #1, it does provide a compatibility shim in another process, running another program, that translates that mechanism onto native systemd mechanisms. (The nosh toolset has its owninitctl-readcompatibility shim that similarly translated into the native mechanisms of the nosh toolset's system management.)initctlreally isn't native to anything but System Vinit, as the others (if they do so at all) only implement the notion of run levels as a limited backwards-compatibility mechanism.initprogram says, theinitctlmechanism isn't well documented. Even the System Vinitpeople go around telling people that only things in the System Vinitpackage should use it. It doesn't help, moreover, that the Debian System V maintainers relocated it from/devto/run.So yes, programs do IPC with process #1. Their reasons for doing so vary.
systemdprogram is a combination system manager, service manager, and control groups manager and so there are a lot of purposes for which programs employ IPC to process #1. The same for upstart'sinit.system-manager, conversely, service management is done by another program (service-manager) in another process with its own (daemontools-compatible) APIs. So the only reason to do IPC with process #1 is for system state management, such as (say) rebooting the machine.For many (not all) purposes, one is better off sticking to other APIs, using conventional system utilities to do things like shutdown and reboot the system, rather than sending the signals understood by the
system-managerandsystemdprograms when they are running as process #1.Further reading