[SSSD] [PATCH] - SIGUSR2 should force SSSD to reread resolv.conf as well

Michal Židek mzidek at redhat.com
Wed Sep 5 11:21:31 UTC 2012


On 09/05/2012 03:16 AM, Ariel Barria wrote:
> > Date: Mon, 3 Sep 2012 17:16:53 +0200
> > From: jhrozek at redhat.com
> > To: sssd-devel at lists.fedorahosted.org
> > Subject: Re: [SSSD] [PATCH] - SIGUSR2 should force SSSD to reread 
> resolv.conf as well
> >
> > On Mon, Sep 03, 2012 at 12:14:53AM -0500, Ariel Barria wrote:
> > >
> > > sorry if I made ​​them waste time.
> > > Well after some drawbacks to create the test environment seems to 
> be already.
> > > >Nack. Did you test this?
> > >
> > > >The function monitor_config_file() just adds a file to the list 
> of files
> > > >that are being monitored. What you need to do is call to signal 
> all of
> > > >the monitor's children to perform a res_init() with
> > > >service_signal_res_init().
> > >
> > >
> > > yes, I not knew some features in vimrc.
> > > I added these revisions :)
> > >
> > > >Also, as Dmitri mentioned, *please* fix the whitespace issues. We use
> > > >four spaces for indentation. No tabs, please.
> >
> > Much better, Ariel, thank you!
> >
> > I have two very minor requests to make the patch more readable:
> >
> > 1) I think you can reuse service_signal_dns_reload instead of the
> > new function service_signal_res_init, the two functions are
> > identical. It is good practice to keep the code duplication as low
> > as possible.
>
> done.
>
> > 2) I don't understand why you pass the private void pointer to
> > signal_res_init() instead of passing struct mt_ctx * directly?
> > Can you either pass the monitor context directly or fold
> > signal_res_init() into signal_offline_reset()
>
> I spent monitor context directly.
>
> > Functionally, the patch is fine. Thanks again.
> thank to you for your comment.
>
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Looks good to me.
Ack.

Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120905/7849180c/attachment.html>


More information about the sssd-devel mailing list