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 <[email protected]> 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 > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
