The problem can be reproduced when DS fails to start (e.g. if one plugin is not started because of missing dependency), next sucessful start bdb_start is called with a bdb_recovery_required that triggers the message: Detected Disorderly Shutdown.
I am not sure it is required to run a db recovery at that time as the database has been closed properly.

(In reply to thierry bordaz from comment #1)
> The problem can be reproduced when DS fails to start (e.g. if one plugin is
> not started because of missing dependency), next sucessful start bdb_start
> is called with a bdb_recovery_required that triggers the message: Detected
> Disorderly Shutdown.
> I am not sure it is required to run a db recovery at that time as the
> database has been closed properly.

I thought the message is logged at a restart after import, thought that the offline import was tampering with the guardian file

And I think it is because of the removed dblayer_close() by #50659

It is possibly related to 50659 but then I am missing something.
During plugin_dependency_startall, it starts dependencies (dblayer_start) but if a dependency is missing (testcase) it just call exit (without calling plugin_closeall) so guardian is not written.
If I understand correctly 50659 it only removes dblayer_close during import.

(In reply to thierry bordaz from comment #4)
> It is possibly related to 50659 but then I am missing something.
> During plugin_dependency_startall, it starts dependencies (dblayer_start)
> but if a dependency is missing (testcase) it just call exit (without calling
> plugin_closeall) so guardian is not written.

but this might be ok, is it new ? Or maybe we are talking about two different test scenarios. If I run tests/suites/plugins/acceptance_test.py::test_acctpolicy I do not see any plugin error, but before 50659 I do not see the disorderly shutdown

> If I understand correctly 50659 it only removes dblayer_close during import.

yes, and in most test cases there is an import during setup

I have a doubt that it is new (related to 50659).
If guardian file (i.e. dblayer_close) is not created, next restart will log 'Detected Disorderly Shutdown' because 'read_metadata' detects a need of recovery.

In the following scenario, plugin_dependency_startall exits without calling dblayer_close. I wonder if it was the case, even before backend refactoring.
dn: cn=account usability plugin,cn=plugins,cn=config
nsslapd-plugin-depends-on-named: attribute uniqueness                                                                                              

dn: cn=attribute uniqueness,cn=plugins,cn=config
nsslapd-pluginEnabled: off

You are probably right. And there is a potential link to #50659

Usually import does not check and write the guardian file. So if your server fails and does not write a guardian file, before +50659 the additional dblayer_close would have written the guardian file if just an import was run after the failure. So this was probably exposed with the removal of dblayer_close() - 
but I am not really sure about it

Upstream ticket:
https://pagure.io/389-ds-base/issue/50741

Fix pushed upstream

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1703