Darren Reed wrote:
> On 17/08/09 04:37 PM, Garrett D'Amore wrote:
>> Nicolas Williams wrote:
>>>
>>>
>>>
>>>> I'm disinclined to support an interface that is substandard *and*
>>>> which does not share widespread adoption in the FOSS community.
>>>>
>>>
>>> In general daemon() is not powerful enough. Often one wants the
>>> process
>>> that calls it to not exit until the progeny forked by daemon() has
>>> completed additional initialization, or perhaps one should not call
>>> daemon() until sundry initialization is complete.
>>>
>>> But daemon() is quite common. Its absence is usually well-tolerated
>>> (#ifndef HAVE_DAEMON ...). But still, we should provide it.
>>>
>>>
>>>> If I've misunderstood about the availability of daemon() in Linux,
>>>> please feel free to correct me. Otherwise I'd be punching the
>>>> derail button on this case.
>>>>
>>>
>>> It's there in libc in RHEL5.
>>>
>>
>> If its there in RHEL5, then I'll withdraw my major concerns. I think
>> the documentation should point users to other, more robust ways of
>> dealing with daemon startup.
>> Last question: Is "Committed" the way to deal with this? If we want
>> to steer developers elsewhere, should we instead just list this
>> interface with "Committed Obsolete" or perhaps "Uncommitted".
>
> Why?
> Would we plan on removing daemon() in the future?
>
> I can't see us replacing it with a function that does anything else...
> I'm sure the discussion would be much more heated if someone
> tried to ARC a daemon() that behaved any differently.
>
> And whilst its functionality may be basic, sometimes that is
> all that is wanted. I see no harm with this being Committed.
>
> Where else can we steer developers?
If daemon() does all that is required, or rather, if we have nothing
better to point developers towards, then I'm happy with the case as
specified.
I got the impression that there were different things that should be
done in the SMF world. I've not developed any daemonized programs since
Solaris 10 introduced SMF (I've been working in kernel space rather), so
I apologize if I was a bit unclear on some of the details.
- Garrett
