0

I'm reading the source code init.c of sysvinit(now replaced by Systemd), in the function spawn()(where init creates subprocesses), there is a comment at line 1165:

    /*
     *  In sysinit, boot, bootwait or single user mode:
     *  for any wait-type subprocess we _force_ the console
     *  to be its controlling tty.
     */

But I'm still not understand it. Could anyone explains the reason in more detail?

Li-Guangda
  • 341
  • 1
  • 4
  • 14
  • Is there, to quote https://stackoverflow.com/help/dont-ask, an "actual problem that you face", or is this simply curiosity? – Charles Duffy Sep 18 '22 at 01:33
  • I don't think I am asking a subjective question. – Li-Guangda Sep 18 '22 at 01:39
  • I'm not arguing that it's subjective; I'm arguing that it's not clear how an answer will change how you go about "the practice of software development" -- thus, whether it's a _practical_ question, which is separate from whether it's objective vs subjective. If what you really mean to ask is "is there some Linux kernel behavior that forces init systems to do this?", the answer is clearly no -- if we look at runit, f/e, it only calls `TIOCSCTTY` once, before forking any child processes (including the `runsvdir` process that supervises all other services). – Charles Duffy Sep 18 '22 at 13:22
  • That said, a common use case for wait-type processes in `/etc/inittab` was gettys. While a getty is supposed to know what it's doing to manage a terminal, I wouldn't be surprised by efforts to let less-competent software do the right thing when inittab tells it to be run on a given terminal. – Charles Duffy Sep 18 '22 at 13:35
  • ...if you really do want to focus on the historical sysvinit rather than having a question that still applies to new development done today, [retrocomputing.se] might be a better place. – Charles Duffy Sep 18 '22 at 13:36

0 Answers0