I have Linux Mint 17.3.
Some of the daemons are initialized with init, some with upstart.
For example, I start the Preload daemon using init. The link is in /etc/rcN.d, but its config file for upstart is missing. The
initctl list daemon is also missing from the
initctl list command output. With all this, the
service preload status says that
preload is running .
But daemons like mdm do not have a reference to themselves in /etc/rcN.d, but have config files for upstart in / etc / init. And they are also launched at startup.
The question is: how does this happen? After all, the initialization process receives PID 1. It seems that there should be only one.
For example, I start the Preload daemon using init
yes, with the "help" of
/sbin/init , which, as you can see, in your case belongs to the upstart package.
it also executes commands from the configuration files
/etc/init/* . one of them is
/etc/init/rc.conf (of course, also from the upstart package), which runs the
/etc/init.d/rc script (from the
sysv-rc package, which is built from the same sources as package
sysvinit ), which, in turn, executes the necessary files (more precisely, symlinks) from the corresponding directories
/etc/rc?.d/ , passing the
Also, the preload daemon is missing from the initctl list command output
this list is by no means listed as "daemons", but (I quote) "known jobs and instances". see the description of the list command in
man initctl .
With all this, the service preload status says that preload is running
if you look at the file
/usr/sbin/service (from the
sysvinit-utils package, which is also built from the same sources as
sysvinit ), you will see that, if necessary, it is "taken" into the same directory
/etc/init.d/ , looks for the corresponding file there and starts it with the passed parameter (in this case –
how is that? After all, the initialization process receives PID 1. It seems that there should be only one.
"How does it happen" I, I hope, explained above.
about process "number 1": this is the only process that the linux program starts directly (and when it terminates abruptly, the linux program "falls" into a kernel panic ). Yes, it is quite logical that this process, when launched, carries out the further operations necessary for the operation of the operating system. in particular, it launches all sorts of different "demons". and what exactly is launched depends on the logic of this program and on its current configuration. and this process (at least at the beginning) is an "avalanche": this or that running program can generate the launch of a bunch of other programs, and so on.
in principle, nothing prevents you, for example, to specify the
init=/bin/bash parameter to the linux program, wait for the shell prompt, and manually start everything that you need: both the preload program and all other services, and get in the end almost exactly a functioning system, as if
/sbin/init (and the programs it ran) were doing all this for you.
it is probably not entirely correct to call process number 1 the "initialization process". this process is engaged not only in initialization, but also takes a direct part in the further work of the operating system (for example, the same sysv -style transition between runlevels ) and in the completion of its work.