[SSSD] [PATCH] exit original process after sssd is initialized

Simo Sorce simo at redhat.com
Fri Oct 19 12:20:13 UTC 2012


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.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list