Steve Litt <slitt@???> writes:
> Rainer Weikusat via Dng said on Mon, 06 Mar 2023 22:11:57 +0000
>
>>Antoine <tacredips@???> writes:
>>> On Monday, 6 March at 16:58, Hendrik Boom wrote:
>>>>On Mon, Mar 06, 2023 at 07:15:23PM +0100, aitor wrote:
>>>>>
>>>>> One of the drawbacks of sysvinit is that it cannot run daemons in
>>>>> the foreground. As opposed to it, daemons supervised by runit must
>>>>> necessarily run in the foreground, but often they have been
>>>>> designed to run in the background with sysvinit in mind.
>>>>
>>>>What is the difference between 'foreground' and 'background' in this
>>>>context?
>
> [snip]
>
>>In this context, 'foreground' means the daemon program
>>runs as child of the process which started it (which can therefore also
>>wait for it to get its termination status and possibly, restart
>>it). 'Background' means the daemon program (or something else) forked
>>once more and the original process exited. The daemon program now runs
>>in an orphaned process which is unrelated to the one which originally
>>started it.
>>
>>That's a bit oversimplified (eg, a background process will usually also
>>change its session) but generally correct.
>
> I think the preceding is the answer to the original question. I'd add
> that the background process backgrounds itself through a double fork to
> reparent itself to PID1 and to give up its attachment to any terminal.

[After calling setsid to create a new session]

Under SVR4, some people recommend calling fork again at this point and
having the parent terminate. The second child continues as the
daemon. This guarantees that the daemon is not a session leader, which
prevents it from acquiring a controlling terminal under SVR4
rules. Alternatively, to avoid acquiring a controlling terminal, be sure
to specify O_NOCTTY whenever opening a terminal device.
[Stevens, APUE p. 417]

But that's a bit beyond the scope of the question.

> Traditionally, this type of daemon would remain in foreground until it
> was functional, and then doublefork itself, at which time sysvinit
> would run the next daemon.

That's an urban myth. There is no such convention and "daemon readiness"
isn't a well-defined concept. Current implementations of SysV-RC start
jobs in parallell (and have for some time).