On 08/05/2016 11:41 AM, Pavel Březina wrote:
Hi list,
LGTM
I am waiting or CI.
Regards
On 08/05/2016 12:19 PM, Petr Cech wrote:
On 08/05/2016 11:41 AM, Pavel Březina wrote:
Hi list,
LGTM
I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
On 08/05/2016 01:02 PM, Petr Cech wrote:
On 08/05/2016 12:19 PM, Petr Cech wrote:
On 08/05/2016 11:41 AM, Pavel Březina wrote:
Hi list,
LGTM
I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
Not connected.
On 08/08/2016 10:26 AM, Pavel Březina wrote:
On 08/05/2016 01:02 PM, Petr Cech wrote:
On 08/05/2016 12:19 PM, Petr Cech wrote:
On 08/05/2016 11:41 AM, Pavel Březina wrote:
Hi list,
LGTM
I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
Not connected.
ACK
On Mon, Aug 08, 2016 at 10:28:41AM +0200, Petr Cech wrote:
On 08/08/2016 10:26 AM, Pavel Březina wrote:
On 08/05/2016 01:02 PM, Petr Cech wrote:
On 08/05/2016 12:19 PM, Petr Cech wrote:
On 08/05/2016 11:41 AM, Pavel Březina wrote:
Hi list,
LGTM
I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
Not connected.
ACK
* master: a16e7a370d0b564a5edad7791d2421d175c0787a
On Tue, Aug 09, 2016 at 10:39:25AM +0200, Jakub Hrozek wrote:
On Mon, Aug 08, 2016 at 10:28:41AM +0200, Petr Cech wrote:
On 08/08/2016 10:26 AM, Pavel Březina wrote:
On 08/05/2016 01:02 PM, Petr Cech wrote:
On 08/05/2016 12:19 PM, Petr Cech wrote:
On 08/05/2016 11:41 AM, Pavel Březina wrote:
Hi list,
LGTM
I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
Not connected.
ACK
- master: a16e7a370d0b564a5edad7791d2421d175c0787a
By the way, even though sssd started, so the bug is fixed, the time it takes for the first lookup is IMO just too long. We should abort the identity lookups sooner and just go to the cache, otherwise lookups on system startup might delay the init process.
Do you want me to open another bug?
On 08/09/2016 10:53 AM, Jakub Hrozek wrote:
On Tue, Aug 09, 2016 at 10:39:25AM +0200, Jakub Hrozek wrote:
On Mon, Aug 08, 2016 at 10:28:41AM +0200, Petr Cech wrote:
On 08/08/2016 10:26 AM, Pavel Březina wrote:
On 08/05/2016 01:02 PM, Petr Cech wrote:
On 08/05/2016 12:19 PM, Petr Cech wrote:
On 08/05/2016 11:41 AM, Pavel Březina wrote: > https://fedorahosted.org/sssd/ticket/3111
Hi list,
LGTM
I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
Not connected.
ACK
- master: a16e7a370d0b564a5edad7791d2421d175c0787a
By the way, even though sssd started, so the bug is fixed, the time it takes for the first lookup is IMO just too long. We should abort the identity lookups sooner and just go to the cache, otherwise lookups on system startup might delay the init process.
Do you want me to open another bug?
Code hangs in gethostbyname in ldap. Timeouts have the same value as in previous versions.
On Tue, Aug 09, 2016 at 11:03:43AM +0200, Pavel Březina wrote:
On 08/09/2016 10:53 AM, Jakub Hrozek wrote:
On Tue, Aug 09, 2016 at 10:39:25AM +0200, Jakub Hrozek wrote:
On Mon, Aug 08, 2016 at 10:28:41AM +0200, Petr Cech wrote:
On 08/08/2016 10:26 AM, Pavel Březina wrote:
On 08/05/2016 01:02 PM, Petr Cech wrote:
On 08/05/2016 12:19 PM, Petr Cech wrote: > On 08/05/2016 11:41 AM, Pavel Březina wrote: > > https://fedorahosted.org/sssd/ticket/3111 > > Hi list, > > LGTM > > I am waiting or CI.
CI: http://sssd-ci.duckdns.org/logs/job/50/88/summary.html
It failed on F24 on dyndns: http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-...
It failed by reaching timeout. I think, it is not connected. What do you think, Pavel?
Regards
Not connected.
ACK
- master: a16e7a370d0b564a5edad7791d2421d175c0787a
By the way, even though sssd started, so the bug is fixed, the time it takes for the first lookup is IMO just too long. We should abort the identity lookups sooner and just go to the cache, otherwise lookups on system startup might delay the init process.
Do you want me to open another bug?
Code hangs in gethostbyname in ldap. Timeouts have the same value as in previous versions.
Yes, but can the responder abort the request sooner?
On 08/09/2016 11:08 AM, Jakub Hrozek wrote:
On Tue, Aug 09, 2016 at 11:03:43AM +0200, Pavel Březina wrote:
On 08/09/2016 10:53 AM, Jakub Hrozek wrote:
On Tue, Aug 09, 2016 at 10:39:25AM +0200, Jakub Hrozek wrote:
On Mon, Aug 08, 2016 at 10:28:41AM +0200, Petr Cech wrote:
On 08/08/2016 10:26 AM, Pavel Březina wrote:
On 08/05/2016 01:02 PM, Petr Cech wrote: > On 08/05/2016 12:19 PM, Petr Cech wrote: >> On 08/05/2016 11:41 AM, Pavel Březina wrote: >>> https://fedorahosted.org/sssd/ticket/3111 >> >> Hi list, >> >> LGTM >> >> I am waiting or CI. > > CI: > http://sssd-ci.duckdns.org/logs/job/50/88/summary.html > > It failed on F24 on dyndns: > http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-... > > > > It failed by reaching timeout. I think, it is not connected. What do you > think, Pavel? > > Regards >
Not connected.
ACK
- master: a16e7a370d0b564a5edad7791d2421d175c0787a
By the way, even though sssd started, so the bug is fixed, the time it takes for the first lookup is IMO just too long. We should abort the identity lookups sooner and just go to the cache, otherwise lookups on system startup might delay the init process.
Do you want me to open another bug?
Code hangs in gethostbyname in ldap. Timeouts have the same value as in previous versions.
Yes, but can the responder abort the request sooner?
Currently the timeout on responder side is 150 seconds. This can be decreased, but is it safe to descrease it to lower value than 10? (I think 10 seconds is the timeout in gethostbyname).
On Tue, Aug 09, 2016 at 11:15:29AM +0200, Pavel Březina wrote:
On 08/09/2016 11:08 AM, Jakub Hrozek wrote:
On Tue, Aug 09, 2016 at 11:03:43AM +0200, Pavel Březina wrote:
On 08/09/2016 10:53 AM, Jakub Hrozek wrote:
On Tue, Aug 09, 2016 at 10:39:25AM +0200, Jakub Hrozek wrote:
On Mon, Aug 08, 2016 at 10:28:41AM +0200, Petr Cech wrote:
On 08/08/2016 10:26 AM, Pavel Březina wrote: > On 08/05/2016 01:02 PM, Petr Cech wrote: > > On 08/05/2016 12:19 PM, Petr Cech wrote: > > > On 08/05/2016 11:41 AM, Pavel Březina wrote: > > > > https://fedorahosted.org/sssd/ticket/3111 > > > > > > Hi list, > > > > > > LGTM > > > > > > I am waiting or CI. > > > > CI: > > http://sssd-ci.duckdns.org/logs/job/50/88/summary.html > > > > It failed on F24 on dyndns: > > http://sssd-ci.duckdns.org/logs/job/50/88/fedora24/ci-build-coverage/dyndns-... > > > > > > > > It failed by reaching timeout. I think, it is not connected. What do you > > think, Pavel? > > > > Regards > > > > Not connected.
ACK
- master: a16e7a370d0b564a5edad7791d2421d175c0787a
By the way, even though sssd started, so the bug is fixed, the time it takes for the first lookup is IMO just too long. We should abort the identity lookups sooner and just go to the cache, otherwise lookups on system startup might delay the init process.
Do you want me to open another bug?
Code hangs in gethostbyname in ldap. Timeouts have the same value as in previous versions.
Yes, but can the responder abort the request sooner?
Currently the timeout on responder side is 150 seconds. This can be decreased, but is it safe to descrease it to lower value than 10? (I think 10 seconds is the timeout in gethostbyname).
For user lookups, I think it can, I don't think a user lookup should take that long. but initgroups and group requests shold have a longer timeout. It might also be nice to use a different timeout for cases where there is something in the cache (and we have something to return) and where the cache is totally empty.
But this is not that important, unless someone hits a case where this breaks some scenario.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Pavel Březina -
Petr Cech