Hi,

<<
The part I am wondering about has to do with what kind of model actual
sysvinit follows. In regular devuan, I see that my daemons are children
of PID 1 which is /sbin/init.
>>

As far as I have understood, /sbin/init calls /etc/init.d/rc X to load
the OS which means it is the script that loads daemons. In fact, I am
successfully loading a functional OS simply by letting Felker's init
to execve a custom script I wrote that first calls /etc/init.d/rc S
and then /etc/init.d/rc 2.

Studying /sbin/init's code I found that it is quite elaborate and
definitely requires far more time on my part to understand what goes
in init behind the scenes.

Edward

On 17/06/2016, Lars Noodén <lars.nooden@???> wrote:
> On 06/17/2016 08:54 AM, Edward Bartolo wrote:
> [snip]
>> PID 1 should fork only once to run the first script that loads the
>> operating system. Once execution enters the infinite loop there is no
>> way of it jumping to somewhere else. Therefore, only one child is
>> forked. This child should terminate on as soon as the OS loading
>> script terminates. On my system it behaves that way. Forking children
>> indefinitely in absolutely NOT minimal and is highly undesired
>> considering this should be minimal.
>
> Thanks for the explanation. And I understand that the script is purely
> for pedagogical purposes. It works well as an educational demo since it
> is short and uncomplicated. I appreciate it. I think it has helped my
> understanding of how things can work.
>
> The part I am wondering about has to do with what kind of model actual
> sysvinit follows. In regular devuan, I see that my daemons are children
> of PID 1 which is /sbin/init. So, if I may guess, it looks like init
> forks once for each daemon. Then each fork then execs (eventually or
> directly) one of the init scripts in /etc/rc.?/ which uses
> /sbin/start-stop-daemon to exec the daemon itself. Thus through the
> cascade of execs, the daemon inherits the PID of the fork and the PPID
> of init. Is that more or less what sysvinit is doing?
>
> Regards,
> Lars
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>