> On 6 Feb 2020, at 18:40, Ludwig Krispenz wrote:
>
>
> On 02/06/2020 12:57 AM, William Brown wrote:
>>
>>> On 5 Feb 2020, at 20:08, Ludwig Krispenz wrote:
>>>
>>>
>>> On 02/05/2020 10:53 AM, thierry bordaz wrote:
On 2/5/20 2:30 AM, William Brown wrote:
>> On 5 Feb 2020, at
On 02/06/2020 12:57 AM, William Brown wrote:
On 5 Feb 2020, at 20:08, Ludwig Krispenz wrote:
On 02/05/2020 10:53 AM, thierry bordaz wrote:
On 2/5/20 2:30 AM, William Brown wrote:
On 5 Feb 2020, at 03:10, Ludwig Krispenz wrote:
I think I can agree with 1-8, 9 is one solution to fix the
> On 5 Feb 2020, at 20:08, Ludwig Krispenz wrote:
>
>
> On 02/05/2020 10:53 AM, thierry bordaz wrote:
>>
>>
>> On 2/5/20 2:30 AM, William Brown wrote:
>>>
On 5 Feb 2020, at 03:10, Ludwig Krispenz wrote:
I think I can agree with 1-8, 9 is one solution to fix the problem you
On 02/05/2020 10:53 AM, thierry bordaz wrote:
On 2/5/20 2:30 AM, William Brown wrote:
On 5 Feb 2020, at 03:10, Ludwig Krispenz wrote:
I think I can agree with 1-8, 9 is one solution to fix the problem
you reported, but not yet validate that there are no other side
effects, there are
On 2/5/20 2:30 AM, William Brown wrote:
On 5 Feb 2020, at 03:10, Ludwig Krispenz wrote:
I think I can agree with 1-8, 9 is one solution to fix the problem you
reported, but not yet validate that there are no other side effects, there are
potential postop plugins which should NOT be
> On 5 Feb 2020, at 03:10, Ludwig Krispenz wrote:
>
> I think I can agree with 1-8, 9 is one solution to fix the problem you
> reported, but not yet validate that there are no other side effects, there
> are potential postop plugins which should NOT be called for tombstone delete,
> eg
I think I can agree with 1-8, 9 is one solution to fix the problem you
reported, but not yet validate that there are no other side effects,
there are potential postop plugins which should NOT be called for
tombstone delete, eg retro cl, we need to investigate side effects of
the patch and
Hi,
I agree with you that calls to pre and post should be balance, but not
sure if your approach is the correct one. There is a condition for post
"!delete_tombstone_entries" which prevented the call for postop plugins
in case of the deletion of a tombstone entry. Your patch now ensures
that
Ok, let's take this from the top:
1: Defects that cause a server to become unresponsive are bad and must
be repaired as soon as possible.
2: Some #1 class defects are exploitable and require a CVE. As far as
I can tell, this one does not, but you should keep an eye out for the
possibility.
3:
> On 3 Feb 2020, at 23:43, Jay Fenlason wrote:
>
> On Mon, Feb 03, 2020 at 10:38:59AM +1000, William Brown wrote:
>>
>>
>>> On 1 Feb 2020, at 12:10, Jay Fenlason wrote:
>>>
>>> I have a small FreeIPA deployment of ~6-8 servers running on Centos
>>> 7.7. Do to the addition and removal of
Here's a backtrace of the hung server:
All of the other threads are in pthread_cond_wait(), select() or poll()
#0 0x7fce1454f35e in pthread_rwlock_wrlock ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_wrlock.S:85
#1 0x7fce16e1acca in slapi_rwlock_wrlock (rwlock=)
at
On Mon, Feb 03, 2020 at 10:38:59AM +1000, William Brown wrote:
>
>
> > On 1 Feb 2020, at 12:10, Jay Fenlason wrote:
> >
> > I have a small FreeIPA deployment of ~6-8 servers running on Centos
> > 7.7. Do to the addition and removal of some of the servers, some
> > cruft (tombstones,
> On 1 Feb 2020, at 12:10, Jay Fenlason wrote:
>
> I have a small FreeIPA deployment of ~6-8 servers running on Centos
> 7.7. Do to the addition and removal of some of the servers, some
> cruft (tombstones, replication conflicts, etc) have crept in to the
> directory. I noticed that when I
On 1/31/20 9:10 PM, Jay Fenlason wrote:
I have a small FreeIPA deployment of ~6-8 servers running on Centos
7.7. Do to the addition and removal of some of the servers, some
cruft (tombstones, replication conflicts, etc) have crept in to the
directory. I noticed that when I attempted to delete
14 matches
Mail list logo
