Hi Julian,
It looks that an update (Thread 62) is either eating CPU either is
blocked while update the changelog.
When it occurs could you run 'top -H -p <pid>' to see if some thread are
eating CPU.
Else (no cpu consumption), you may take a pstack and dump DB lock info
(db_stat -N -C A -h /var/lib/dirsrv/<inst>db)
Did you run admin task (import/export/index...) before it occurred ?
What version are you running ?
best regards
Thierry
On 9/8/23 09:28, Julian Kippels wrote:
Hi,
it happened again and now I ran the gdb-command like Mark suggested.
The Stacktrace is attached. Again I got this error message:
[07/Sep/2023:15:22:43.410333038 +0200] - ERR - ldbm_back_seq -
deadlock retry BAD 1601, err=0 Unexpected dbimpl error code
and the remote program that called also stopped working at that time.
Thanks
Julian Kippels
Am 28.08.23 um 14:28 schrieb Thierry Bordaz:
> Hi Julian,
>
> I agree with Mark suggestion. If new connections are failing a pstack
> + error logged msg would be helpful.
>
> Regarding the error logged. LDAP server relies on a database that,
> under pressure by multiple threads, may end into a db_lock deadlock.
> In such situation the DB, selects one deadlocking thread, returns a
> DB_Deadlock error to that thread while the others threads continue to
> proceed. This is very normal error that is caught by the server that
> simply retries to access the DB. If the same thread fails to many
> time, it stops retry and return a fatal error to the request.
>
> In your case it reports code 1601 that is transient deadlock with
> retry. So the impacted request just retried and likely succeeded.
>
> best regards
> thierry
>
> On 8/24/23 14:46, Mark Reynolds wrote:
>> Hi Julian,
>>
>> It would be helpful to get a pstack/stacktrace so we can see where
>> DS is stuck:
>>
>>
https://www.port389.org/docs/389ds/FAQ/faq.html#sts=Debugging%C2%A0Hangs
>>
>>
>> Thanks,
>> Mark
>>
>> On 8/24/23 4:13 AM, Julian Kippels wrote:
>>> Hi,
>>>
>>> I am using 389-ds Version 2.3.1 and have encountered the same error
>>> twice in three days now. There are some MOD operations and then I
>>> get a line like this in the errors-log:
>>>
>>> [23/Aug/2023:13:27:17.971884067 +0200] - ERR - ldbm_back_seq -
>>> deadlock retry BAD 1601, err=0 Unexpected dbimpl error code
>>>
>>> After this the server keeps running, systemctl status says
>>> everything is fine, but new incoming connections are failing with
>>> timeouts.
>>>
>>> Any advice would be welcome.
>>>
>>> Thanks in advance
>>> Julian Kippels
>>>
>>> _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>>> To unsubscribe send an email to
>>> 389-users-leave(a)lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines:
>>>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>>
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>>> Do not reply to spam, report it:
>>>
https://pagure.io/fedora-infrastructure/new_issue
>>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> Do not reply to spam, report it:
>
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue