On Fri, 2012-10-19 at 09:52 +0200, Pavel Březina wrote:
> On 10/18/2012 08:43 PM, Stephen Gallagher wrote:
>> On 10/18/2012 09:50 AM, Jakub Hrozek wrote:
>>> On Thu, Oct 18, 2012 at 11:28:10AM +0200, Pavel Březina wrote:
>>>> On 10/18/2012 11:15 AM, Pavel Březina wrote:
>>>>>
https://fedorahosted.org/sssd/ticket/1357
>>>>>
>>>>> Neither systemd or our init script use pid file as a notification
>>>>> that sssd is finished initializing. They will continue starting up
>>>>> next service right after the original process is terminated.
>>>>
>>>> Oops, I forgot to amend the patch with latest changes. The final
>>>> patch is attached.
>>>
>>> I haven't really had time to read the patch too carefully yet, but my
>>> first thought was to always try to use tevent signals if you need
>>> signals at all.
>>
>> Yes, I went through a lot of effort a little over a year ago to get the
>> monitor properly using tevent signals instead of managing its own
>> directly. Please do not add manual handlers.
>>
>> Nack.
>
> Hi guys,
> I just want to make sure that we are on the same page here before I
> start modifying it to tevent.
>
> I am not mixing tevent signals with posix signals. There is no existing
> tevent context available and there will never be (unless I create it).
>
> I just need to catch SIGTERM in original process (that forks and become
> monitor), so that monitor can signal the original process to quit. Or
> wait for the monitor to exit (in case of error etc.) if the signal
> doesn't come.
>
> Using tevent for this case seems like using a sledgehammer to crack a
> nut.
Pavel if this is before we create the tevent event context than it is ok
to directly handle signals, however put a comment there taht says so.
example: /* We use signals directly here because we don't have a tevent
context yet */
Simo.
Very well. New patch is attached.