Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

Miloslav Trmač mitr at volny.cz
Fri Nov 11 13:36:00 UTC 2011


On Fri, Nov 11, 2011 at 2:22 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Fri, 11.11.11 14:12, Miloslav Trmač (mitr at volny.cz) wrote:
>
>> On Fri, Nov 11, 2011 at 2:05 PM, Lennart Poettering
>> <mzerqung at 0pointer.de> wrote:
>> > Note that only double-forking
>> > will properly detach a process from the parent it is started from on
>> > Unix, and hence is not an option but mandatory to do
>>
>> In the traditional SysV, the process executing /etc/init.d/$service
>> will exit immediately afterwards.  Isn't that structurally equivalent
>> to double-forking within the service?
>
> No.
>
> In SysV it is expected that when you run "/etc/init.d/foobar start" and
> this command completes the service is fully initialized, the PID file
> written and the service accessible. That means that you need to double
> fork and in the parent process wait until initialization is
> complete.
I can just as well wait in the single-fork parent, can't I?

> On top of that, you need to invoke setsid() between the two forks, which
> you can't really do if you only have one fork().
Again, I should be able to do this in the ultimate child just the same
- the concept of "orphaned process group" (and the related
SIGHUP/SIGCONT behavior) only triggers for process groups within a
single session, and the controlling TTY behavior should not matter for
daemons (although I do agree that having the session leader exit is a
little safer because it ensures that the daemon won't randomly obtain
a controlling TTY).


I can see only one difference - starting the daemon from a command
line within a user's session without double forking would leave the
process "attached" to the user's session in the process tree; however,
given that the process was not actually started by the service
management system in that case, this might arguably be considered a
correct behavior - and in any case doesn't really matter for anything.
   Mirek


More information about the devel mailing list